Compile time evaluation in Nim, Zig, Rust and C++ (castillodel.github.io)

In one thing you're actually right, I should have used a string_view for the return value instead.

    #include <vector>
    #include <string>
    #include <algorithm>
    #include <string>
    #include <cstdio>

    constexpr std::string_view get_fizzbuzz(int number) {
        if (number % 15 == 0) {
            return "FizzBuzz";
        } else if (number % 3 == 0) {
            return "Fizz";
        } else if (number % 5 == 0) {
            return "Buzz";
        }
        return std::to_string(number); // convert to string
    }

    int main() {
        static constexpr auto value = get_fizzbuzz(15);
        puts(value.data());
    }

Having to mark everything as evaluatable at compile time is a stupid, stupid, decision that only C++ could think was a good idea.

Though on the other hand I'm using compile Nim code to parse CMake files and provide static types for configuration values. It's super easy in Nim between macros and const's. Here's a ~170 lines of code where I'm compile time checking that my Nim code can compile time check against the current build configuration of Zephyr RTOS https://github.com/EmbeddedNim/nephyr/blob/main/src/zephyr_c...

I get that this differs from normal file io, but I could argue that is in line with Zig motto of clarity.

Also you would of course suddenly have to have the file content as part of your binary. Maybe you were hoping to be able to throw that away after you generated what you wanted...?

There’s a few awkward-ish parts of the syntax, but in practice those items aren’t big issues (compared to say Rust async syntax issue). For example multi-line lambdas can be done with ‘do’ blocks or just wrapping parens. Identifier equality has actually saved me from a few bugs by accidentally creating a new similarly named variable, say an ‘isDone’ when I already had an ‘is_done’ following the style from C FFI. Though the compiler warns by default when mix naming styles, and can be set as an error if desired.

Iterators usage can be a bit annoying though. I also really enjoy UFCS: https://en.m.wikipedia.org/wiki/Uniform_Function_Call_Syntax

Python comparison example: https://narimiran.github.io//2018/05/10/python-numpy-nim.htm...

    import sequtils

    let x = [1,2,3,4,5]
    echo x.map(
      proc (num: int): int =
        num*2
    )

This is a very surface-level complaint, and it is no surprise that almost everyone who complains about this hasn't actually used the language. I will admit it is indeed a peculiar feature, I wouldn't be able to name another language that did this before, but as it turns out, it has yet to be a problem in practice.

Do you fear some crazy person might mix identifier styles? They could do that in any language, Nim has nothing to do with that. The pro of this feature is that you can write your library in whichever style you prefer, and people can use your library and still use their preferred style, I always hated how in python you often end up having to use libraries written in camelCase for your snake_case project (or vice versa).

Once again, it is a rather peculiar feature, like who asked for this? I don't know, but then again, why not? it did make me raise an eyebrow at first, but in practice, Nim gets it just right. The one valid scenario where it could get in the way is when searching your source files for an identifier, but even then Nim has solutions for that (there's nimgrep, and mainstream editors/IDEs are already nim-aware anyways).

The way I see it, the GC is just nice to have for productivity, and for those cases where you really need to optimize your program, there is nothing stopping you from managing your memory yourself, you can write your own types with their own constructors/destructors (Nim has "scope-based" memory management akin to RAII in C++), of course, you must be aware that using pointers will lead to potentially unsafe code, Nim can't hold your hand there.

That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces). Same goes for Go which enforces the opening brace on same line style. The people writing those languages can have whatever style they like for their code, but forcing me to use it is very off-putting to say the least. I get that this is probably a minor issue for most people but I can't deal with change that well and things like this are super annoying, especially since there is not one single reason for forcing a certain style on everyone.

I'm aware that `#? replace(sub = "\t", by = " ")` works, but it's a hack and I'd have to inject it everywhere, not a good solution. But at least it's better than Go in this regard.

You can do something like the nim without build.rs or proc macros:

    #[derive(Debug, Copy, Clone)]
    enum Value {
        Fizz,
        Buzz,
        FizzBuzz,
        Number(usize),
    }
    
    const fn get_fizzbuzz_equivalent<const N: usize>() -> [Value; N] {
        let mut result = [Value::FizzBuzz; N];
    
        let mut i: usize = 0;
        while i < N {
            let n = i + 1;
            if n % 15 == 0 {
                result[i] = Value::FizzBuzz;
            } else if n % 3 == 0 {
                result[i] = Value::Fizz;
            } else if n % 5 == 0 {
                result[i] = Value::Buzz;
            } else {
                result[i] = Value::Number(n);
            };
    
            i += 1;
        }
    
        result
    }
    
    fn main() {
        const FIZZBUZZ: [Value; 31] = get_fizzbuzz_equivalent();
    
        println!("{:?}", FIZZBUZZ);
    }
    

(Shout-out to https://stackoverflow.com/questions/67538438/const-array-fro... which I basically smashed together with OP's code to produce the above example.)