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.