Compile time evaluation in Nim, Zig, Rust and C++

The ecosystem might be small but as you said it can grow and I think there's enough people out there willing to give a new language a try if it seems appealing enough, it's quite common to try a new language for Advent of Code for example.

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.

It's been a while since I last played around with Nim (back when it was still called Nimrod). But doesn't Nim compile to C and therefore it can interact with the entire C ecosystem? And afaik it is also camel-case-insensitive, so that you can call C functions without having to worry about different naming conventions?

I think the biggest issue is that Nim took a long time to “find its feet”. There was a lot of experimentation before the current sweet spot. Due to its new GC system ‘ARC’ it’s now broadly useable as a systems language, which wasn’t true before with a regular GC. ARC is non-atomic/non-locking reference count based, meaning it can be used to as a systems language (no GC pauses) or for system libraries (C programs can use it).

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...

May I ask what exactly do you dislikes about Nim's garbage collection? You said you "quickly" scanned Nim's page, so I assume you just don't want a GC period? If you're dealing with hard-realtime constraints then I understand. But otherwise, as long as you aren't dealing with cyclic data structures, Nim's GC is just reference counting, which is very widespread in even C++ and Rust code, and if you really want to you can just not use the cycle collector and break the cycles yourself.

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.

What's so awkward about multi line lambdas? You can achieve them in the same way you can in JavaScript, can't get easier than that.

    import sequtils

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

>Identifier equality

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).

I just started to (very slowly) learn Nim, and it's quite nice for the moment. Of course there are some points of friction, but which language doesn't have ? The documentation page has comparison with C, python and typescript/JavaScript https://nim-lang.org/documentation.html

Yeah... using absurd names like that is on the developer, not the programming language. You can do useless stuff like that in any language.

constexpr should just try to evaluate stuff at compile time. In D, most sensible code works at compile time automatically, I don't think about it.

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

It's funny how something like Zig's comptime of C++'s constexpr get 90% of the way to solving most compile time issues, but can't knock out that last 10%. Compile time database types sound like one of those cases. F# had a feature for compile time types via "type providers". It seemed _really_ cool at first, but in practice is was a bit fragile.

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...

Isn't that somewhat possible with @embedFile? Then you get the content of the file as a null terminated byte array / normal zig string. I would think you could do further comptime things to it after that no? I haven't tried it myself so maybe I am missing something.

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...?

Compiler Explorer is your friend, https://godbolt.org/z/94hzK8svE

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());
    }

Like, no. Have you never programmed Python?

To elaborate, the parent doesn't call get_fizzbuzz_equivalent in a "const context", which would require it to be evaluated at compile time. So it's called at runtime like it didn't have `const`.

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.)

Yep, you're perfectly right of course. My "solution" was mainly to address the problem "how can I return a String from a const function"... the answer is that you don't have to :-)

I have, nothing big and nothing finished—the beta now has 150 people in it.