It pains me that Rust targets LLVM, and doesn't use C as an intermediary language.
I would _love_ to use Rust on embedded and older hardware on which LLVM simply isn't available.
I would _love_ to use Rust on embedded and older hardware on which LLVM simply isn't available.
I don't understand why I see so many requests for LLVM-based languages to change around their backend or IR, that seems to be a huge amount of work for comparatively little benefit. The correct thing to do there is to just add support for those to LLVM.
GCC, and various proprietary vendor compilers, are often the only C compilers available on some hardware; and llvm doesn't have a mature, stable and supported backend for them, either.
* The community is tiny. A rounding error compared to Go, Rust, etc.
* The core team of contributors is even smaller. You could comfortably have an intimate dinner party with all of them. If they lose interest, the language would likely die.
* The library distribution story wasn't great last I checked.
Caveat: I haven't used Nim for more than a year now. Maybe all these issues are no longer relevant. I really want it to succeed, but who knows what the future holds.
I'm a C++ developer and, for now, sticking to it on larger projects since I love the thinking behind the C++ evolution over the decades. Rust still feels like a hype/moving target. The big selling point appears to be memory safety, but that's just a detail and not enough to justify a switch. I'm keeping an eye on how Rust and Nim will evolve in the next 5–10 years, but for now, C++, Erlang, and Lisp are my go-to choices for projects which should last the upcoming decades.
The safety is limited to data races, not concurrency or parallelism problems.