I think so, but I think the performance gap is a little larger than I was expecting with Nim effectively compiling to C as an intermediary.
https://programming-language-benchmarks.vercel.app/rust-vs-c
https://programming-language-benchmarks.vercel.app/rust-vs-c
The issue with targeting C is you ended up losing a lot of information about intent. Compilers looking at C have to put a lot of trust that what the programmer wrote was intentional (and thus, unoptimizable).
Rust and C both end up faster than Nim because they are talking directly to the compiler.
IDK enough about Nim to say if it could hit Rust/C speeds if it targeted the LLVM instead, but it would be a lot faster than it currently is targeting C.
> The issue with targeting C is you ended up losing a lot of information about intent. Compilers looking at C have to put a lot of trust that what the programmer wrote was intentional (and thus, unoptimizable).
The same issue exists in C-sourced compiler backends, which is both GCC and LLVM. It’s not exactly a secret that anything which is not strongly exercised by standard C(++) codebases tends to be rather broken for any non-trivial use and takes years to fix (restrict/noalias being the poster child for this, at least in the context of Rust, I think it hasn’t gotten re-disabled yet so it might make a year).
The JVM, for example, doesn't see the same issue so much with non-Java languages. Mainly because (IMO) it's been hosting non-java languages for several years now.
C has nothing to do with performance, runtimes and libraries do. Nim has runtime overhead whereas C and Rust do not.
Not expecting it to match Rust or C in performance, just surprised at the size of the gap.
Would be interesting to see what the generated C is like from the Nim code.
Just did a few quick tests. A hello world in nim is a one liner:
echo "hello world"
If you don't use automatically managed types like seq/string and ref, there is no GC underneath. And even then, the GC is just reference counting so no difference from Rust Rc/Arc.