Nim is also easier to learn - if you know Python and any conventional statically typed language, it's a walk in the park. I was producing fast, working code in a couple of hours.
Learn Rust for your job, Nim for your side projects.
Learn Rust for your job, Nim for your side projects.
1.) Moves / borrowing / memory model 2.) Adopting a more functional style [to support 1.)]
My observation is that a lot of people /really/ want Rust to be imperative and treat it very imperatively they fight the borrow checker way more than if they adopt the idiomatic norms of Rust. There are some edge case data structures that can be a little painful and require some specialized knowledge, but once you are into Rust I don't even think it is unpleasant for side projects and general purpose hacking, but to get there it demands a higher level of mastery than most languages, but when you get there it can feel extremely productive.
Other languages just require a lot more trial and error to get them to do what you want. Rust, if it compiles, generally does what you expected.
It's not just type safety and the borrow checking either, it's the idioms, std lib, and other language design choices that lead on to improved devex in the wider ecosystem as a result.
I understand you can get the same features out of modern C++ now days but it's not just the features, it's everything that comes with it.
It's kind of the difference between "I want to make a camera" and "I want to mod a camera". Making means controlling the design from the beginning, and Rust is one of the best available tools for that. But modding is more like what you do when you want to bodge together some pieces of I/O and data processing. Apps dealing with audio and graphics in any fine-grained sense tend to want the latter: they aren't actually dealing with resource management issues that often, especially not in the "weekend hack" stage, they just need low latency device access and a fast-enough inner loop. And those requirements imposed a massive, non-obvious barrier to entry on stuff with a substantial VM runtime: writing bindings, remapping ABI semantics, etc. You had to learn a lot of concepts, possibly more than are needed for writing useful Rust code, to overcome that. Rust demands just that you use certain kinds of documented idioms to get through a typical coding problem, while fighting with compilers and linkers to create bindings is a no-mans-land of debugging the meaning of each error message, silent failure or crash, requiring you to know two languages, the build system, the binary formats, and the OS you're targeting simultaneously.
For a long time, C++, for all its faults, was the prosumer's tool of choice for coding near to the metal while still leveraging existing tech, because it was what the toolchains actually supported directly, which let you get ypur weekend hack working piecemeal, while using something else introduced unacceptable levels of overhead.
But I think there are now justifications to use Rust in some cases and Zig or Nim in others. I've kicked the tires on all three, and can vouch for Nim feeling productive in the sense of being both relatively C-friendly as a build environment(lots of features for high-permissiveness hacking) and also occupying a "default to high-level methods" mindset. D could have gotten there in an alternate reality, I think, but it was trying really hard to be big-systems code instead of hacker's glue, which has saddled it with an awkward design story. The things D wanted to do well, Rust now mostly occupies.
If you or anyone else ever has to maintain it that technical debt almost always comes calling and it can often be unpleasant. For personal projects, oh well, you move on, maybe you can throw it out. For even small professional projects you are now in the "Find Out" phase of technical debt. So I am just in this mindset of writing meaningful things and saving experiments for truly throw away code, which still has its place. I am gonna go ahead with Rust as my next 5+ year language, a role Go and Python filled. I think my litmus for Python vs. Rust is if it will take me more than a day (estimate) to write, I am going to suck it up and use Rust.
I also regularly run into utterly infuriating bugs while trying to accomplish what I thought would be simple things. Don't expect to be able to get anything useful done using iterators. They're zero-cost only if you don't value your own time.
On the other hand, all of Rust's docs are a joy and I haven't run into many technical problems so far.
I really want to love Nim.
"..the JVM's largesse isn't aging particularly well. It will die with my generation's retirement."
I call this fundamental blindness considering the JVM is improving dramatically year after year - now even supports lightweight concurrency like Go in 2022.
Java will still be alive and kicking when no one alive even remembers Nim.
The online documentation, certainly, could be better. I sometimes find standard library documentation lacking in examples, and compiler documentation is currently undergoing a massive refactoring effort on a couple of fronts. But the manual (https://nim-lang.github.io/Nim/manual.html) isn't half bad.
I knew someone would say this: it doesn't tell you that, does it? It's supposed to be an introductory reference work, so surely "how to install the 3rd party package required by our hello world example" should be included?
And anyway, even after I installed pixels the code still didn't run right.
I honestly found it insulting that such an expensive book would have such obvious oversights. It's like nobody proofread it at all.
I don't want to take a picture because I already wrote in the book and I don't want people to see my handwriting. But here is some verbatim text from that single page:
>In this chapter we will show the basics of Nim language
needs a "the" before Nim
>(types, for loops, if and case statements, procedures, etc.) while using basic graphic primitives to create shapes
needs a comma after the close parenthesis
>The premise is that the `putPixel` proc exists and we can use it, ...
"proc" is a nonstandard technical term that has not been defined properly yet
>All we need to know is: that proc takes the x and y coordinate of a point ...
colon should not be there, and it needs a "the" before "proc"
In and of themselves these are fairly minor problems, but the whole book is like this. All are forgivable in say, a blog post, but this is a book I paid good money for. It's shoddy work, evincing a lack of care. Not to mention, the print quality is poor.
I enjoyed learning Nim syntax through exercism.io (not affiliated, just really enjoy it as a tool), but I'll be honest that I have no clue if it will become an ungoverned mess or thrive.
Hey @G/Xooglers, Linux Foundation, etc., consider supporting Nim!
I kept hearing the comparisons to Python so I thought it'd be interesting to pick up but the syntax and naming was so counter to Python that that expectation made me immediately bounce off of it.