[elcritch]

The distinction between compilation and transpiling is a bit imprecise, but yes. But oddly the basic C that Nim compiles to is fairly resilient and stable. I'd actually expect the Nim compiler to bitrot way less than languages based on LLVM, which have a very short half life.

So Nim's approach has some challenges, but surprisingly has less moving parts than you'd think. I'd be confident I could get the current Nim compiler up and running in 5, or 10 years with minimal effort.

However, there was a lot of effort to get things like pointers and strings in the stdlib to play nicely across the NimVM, JS, and C backends. Theres some gross details there. But in the end its beautiful.

[cb321]

Besides @elcritch's and @pjmlp's excellent points {language "level" is vague & all compilers translate}, C as a backend target has other virtues (though is by no means The Only Way). E.g., TinyC/tcc optimizes for time to compile (it is a single pass over its input) not generated object code qualities like run-time/file-size. This can give Nim code almost interpreter-like edit-compile-debug devel cycles, but even just changing the default gcc -Og to gcc -O0 can be a huge improvement. [1] (`passL:"-lm" --mm:markAndSweep` and recently `--threads:off` became necessary for tcc due to atomics/C11 dependencies, but it is already a kind of "debugging compilation mode".) Similarly, work on space-saving/alternate libc's like musl [2] can be leveraged, [3] although using `config.nims`/NimScript can also lengthen compile-times by 100 milliseconds or so.

[1] https://forum.nim-lang.org/t/8677 [2] https://musl.libc.org/ [3] https://github.com/kaushalmodi/hello_musl/blob/master/config...