Well, that's kinda the point. If there was a better way to have to achieve GC-free semantics, Rust would have taken it.

As for optional GC, didn't D haven't something along those lines?

Like Nim you can disable the GC in D.

AFAIK, most libraries won't handle that situation gracefully as they don't expect it.

Optional gc is tricky, as you would need all libraries written this way

This is one of the reasons why the Objective-C GC failed.

It just didn't work out mixing Frameworks compiled in different modes, many times leading to crashes.

I believe you can turn off the GC for Nim. Then you're just limited to libraries that don't rely on the GC, and fully manual memory management.

This is more of an option than you might think. Nim plugs in to C libraries much easier than you would expect from an FFI. That means even if the stdlib depends on the GC heavily, you can eschew it for the C stdlib.

For example:

    proc printf(formatstr: cstring) {.header: "<stdio.h>", importc: "printf", varargs.}

I'd be interested in seeing a comparison of higher level language features rather than performance (which is generally a result of data structure choices, etc). Stuff like package managers, concurrency primitives, cross compiler support, memory management, and general syntax.

Wow, that's a pretty cool insight. Basically that means you could use "Nim without GC" as "a better C". I can see very few downsides. You could probably start using it in existing C projects much like you could start adding .scala files to an existing Java project.

As an example, that's exactly what I'm doing with my SDL game experiments; I'm using Nim as a "better C", effectively. It works rather brilliantly.

That isn't Rust's semantics though (as specified in the parent post): Rust's semantics are about ensuring safe manual memory management.