Nim doesn't meet all his requirements, it's garbage-collected. Complexity is hard to measure and rather subjective, but Nim in my opinion seems to be more complex than Zig.
> Nim in my opinion seems to be more complex than Zig
That may be so, but Zig is still in a very early stage of development. A language may look simple and fresh in the beginning, but the real test comes when 1.0 is right around the corner. Nim is at this stage now, I am one of the Nim core devs and I will even admit that it is by no means simple, there are features that I would like to see removed to reduce the complexities, but how do you do that when a vocal percentage of your user base loves the feature?
Do keep this in mind when trying to compare a language like Zig (which is just starting out) to a language like Nim (which has been around for a while). Perhaps Zig will do a better job than Nim in this regard, but only time can tell.
You can also point out that people can use subsets with minimal features. They can do it for extra safety, consistency, or even low-level control. Safety-critical field has done that with both C++ and Java for some time now.
Regarding that, does Nim allow one to turn off GC, mess with pointers, and twiddle bits like in C? As in, is there an optional set of C's features in there that one can use? Or improve with macros, type-safe wrappers, and so on?
> Safety-critical field has done that with both C++ and Java for some time now.
Every company/project uses a subset of C++ for a variety of reasons. The problem is, all those subsets are different, and as a result, if you want to rely on the ecosystem, you eventually have to deal with the entire language. Maybe you avoid exceptions/pointers/new&delete/template-meta-programming/the-coprocessor, but the libraries you need don't.
This is visible already in Nim, where the GC is optional, but most libraries (and most of the standard library) does depend on it.
It works well without GC, but you lose out on most of the existing libraries and many parts of the ecosystem.
> Regarding that, does Nim allow one to turn off GC, mess with pointers, and twiddle bits like in C?
It lets you twiddle bits without having to turn off the GC - it has GC-tracked pointers ("ref"s) and non-GC ones ("ptr"s). the GC is per-thread, with time limits but it can also be turned off.
> Or improve with macros, type-safe wrappers, and so on?
Nim macros are not quite at the Lisp level, but they are extremely powerful.
There are various features for type safety that DON'T require wrappers, e.g. you could define "meters" and "yards" as two distinct 64-bit double types, which means you can't add them or assign one to a variable of the other kind, even though they are still essentially a C-style typedef. This is a much more elegant solution than the C++/Python/SmallTalk/Java/C# crowd, where you have to define a class with a lot of methods, which is still clunky, and hope that the compiler will be able to optimize it back down to a plain old double.
Lisp has reader macros that can alter lexical analysis and parsing; correct me if I am wrong, but I think that’s not possible in Nim. E.g. things like JSX are trivial to implement in Lisp.
Also, lisp macros let you e.g. write new control structures with multiple “body” parts - iirc, in nim only the last untyped macro arg can be a code body (you can put a block in parantheses, but that’s not as elegant)
I’m sure there’s other stuff that fexprs and other [a-z]exprs can do that nim can’t, but i’Ve never seen them in use (or used them myself)
Also, personally I think Nim’s model is more practical; lisp’s power essentially requires lispy or REBOLy syntax to be usable. Nim is pascalythonesque, and though complex is not complicated; much like Python, and unlike C++, you can make use of the ecosystem without being afraid of obscure details biting you - but it has all the capabilities when you need them.
> Regarding that, does Nim allow one to turn off GC, mess with pointers, and twiddle bits like in C? As in, is there an optional set of C's features in there that one can use? Or improve with macros, type-safe wrappers, and so on?
Yep, and in fact I would say that Nim is a perfect "better C" language. You get things like modules, a better type system and metaprogramming. Of course you'll have to forgo a lot of the stdlib, but if you're already using C that won't be a tough pill to swallow.
Nim is optionally garbage collected. Most of the standard library opts to use the garbage collector, true, but here's an example of a beginning of a tiny OS kernel in nim[0], that does not.
I do not know enough of Zig to compare the complexity, and Nim is indeed not simple. To borrow from the zen of Python, it is complex but not complicated; and most of its complexity is of a kind you can almost entirely ignore until you need it, and when you need it, you're in trouble if your programming language doesn't provide it. e.g. operational transforms, macros, compile time execution. pragmas.
That may be so, but Zig is still in a very early stage of development. A language may look simple and fresh in the beginning, but the real test comes when 1.0 is right around the corner. Nim is at this stage now, I am one of the Nim core devs and I will even admit that it is by no means simple, there are features that I would like to see removed to reduce the complexities, but how do you do that when a vocal percentage of your user base loves the feature?
Do keep this in mind when trying to compare a language like Zig (which is just starting out) to a language like Nim (which has been around for a while). Perhaps Zig will do a better job than Nim in this regard, but only time can tell.