> What I said above ("Nim is almost never the best choice for any field...")
> unfortunately(?) also has an analog in "Nim is not the [superlative]". Nim
> probably will never reach 100% of C's speed,
Yes, Nim isn't perfect, but I don't find that execution speed is one of its
problems. As it can be thought of as a better syntax front end for C/C++ in
many respects, it has the same options available to optimize execution speed as
those languages do, especially as it can have garbage collection turned off or
bypassed to compare on the same playing field.
So, even though array/seq access through normal indexing methods is already
quite fast, for some specialized tight loops such as one might employ in
extreme manual loop unrolling, one can use (unsafe) pointers and the code gets
optimized to the same as would be produced from C/C++.
In fact, it looks like my current project is turning out to be faster that the
comparable programs written in C/C++ but that isn't due to the languages but
rather just the different algorithm, and I'm sure that if one translated my
algorithm into C/C++ then it would run essentially at the same speed.
The thing I am fighting as "not nice" is the use of multi-threading due to the
current state of thread memory management limitations (no common GC'd heap) and
especially that since the environment part of closures get written to the local
heap that it isn't easy to send closure-acting functions across to different
threads, but, as has been said I think by @Araq somewhere on this thread,
multi-threading isn't very nice on C/c++ either.
On thing that is slow if one needs to write things that depend on it is GC with
all the problems that go along with GC in indeterminate lags and disposal, etc.
Fortunately, we don't have to use it although when we don't we need to forgo
its conveniences and build some of out own structures to replace the built-in
seq's and strings, but it's doable.
Threading and functional programming seem to be the easiest to use on GC memory
managed languages as in F# and Haskell and just don't seem to play all that
well on more imperative languages. In fact, things may get worse if Nim
transitions to an ownership/RC'ed memory management model as recently proposed:
[https://forum.nim-lang.org/t/4743#29760](https://forum.nim-lang.org/t/4743#29760)
and discussed:
[https://forum.nim-lang.org/t/4743#29760](https://forum.nim-lang.org/t/4743#29760)
in that in is extremely messy to do purely functional programming in Rust,
which uses an ownership model, and threading may not be so efficient due to the
problems of transferring ownership across closures and threads.
However, I'm looking into doing things with @Araq's latest memory management
proposal and that may be better...
