5 ms·

I'm choosing between learning Nim or Rust. Nim frankly looks like the nicer of the two, but also less marketable and with smaller community. Suck to say but it

I'm choosing between learning Nim or Rust. Nim frankly looks like the nicer of the two, but also less marketable and with smaller community. Suck to say but it's true.

PixyMisa 4y ago
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.
- tomrod 4y ago
  Does Nim have any large groups sponsoring? Part of the appeal of Rust is that it will be around in 20 years due to so many groups adopting it and maturing its governance. 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.
  - sigzero 4y ago
    https://nim-lang.org/sponsors.html https://nim-lang.org/sponsors.html
    - tomrod 4y ago
      Ah, so its definitely a passion project with only about $21k in direct funding per month as of last update (2019). Hey @G/Xooglers, Linux Foundation, etc., consider supporting Nim!
- memco 4y ago
  I had a similar experience. I took a very small project from Python and turned it into Nim: it was about six times as fast to run and took roughly the same amount of code in both. I have plans to learn more but this article is actually a little more fuel for my fire as I think one of my next explorations would be transferring and running code on other systems. If portability is as easy I could see this being used for some work tools I am building. We will almost surely never replace the current language all the major code is written in, but for small self-contained tools it would be great.
- bitexploder 4y ago
  Something I long assumed about Rust before really getting started is that it is /slower/ to develop with. And at first that is definitely true because it introduces some pretty big, powerful, and constraining things. When you learn to work with these things and have taken your lumps discussing your code with `rustc` it is a lot of fun. 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.
  - syntheweave 4y ago
    Rust's sphere of necessary domain knowledge is higher than average. That's not a downside relative to the goal it has in mind, but it is a trade-off. When you're an indie developer working on a side project, there's a strong impulse to let go of a lot of the specific quality controls and customizations that you can use in a team setting where you're paid to know how to operate the inner workings, and instead look for something that is "prosumer" and lets you hack out a solution. 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.
- _dain_ 4y ago
  I'm learning Rust now, I can say Nim is much harder. Maybe the language itself is simpler, but the documentation is just not very good. Very unpolished and amateurish. I actually forked out fifty quid for Araq's "Mastering Nim" book; it is atrocious. Spelling and grammatical errors on every page. The very first code example did not compile. 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.
  - planetis 4y ago
    I have the book, and it's an excellent resource for the language. I might be a little biased because I am a long time Nim user but definitely so are you.
  - winrid 4y ago
    Yeah, I wrote an equivalent service in Java and Nim, and I just couldn't get Nim to perform as well as Java, and it wasn't even easy to write. Random segfaults, depending on memory manager used, random libraries requiring different memory managers, ORC being talked about a lot despite causing random segfaults, and so on. I really want to love Nim.
    - lenkite 4y ago
      Author's take on Java is really funny. "..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.
      - wiseowise 4y ago
        Not only Java, but major JVM languages as well (Clojure, Kotlin, Scala).
- epage 4y ago
  > Nim is also easier to learn - if you know Python and any conventional statically typed language, it's a walk in the park. I 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.
anyfactor 4y ago
I honestly don't think your options should be between Nim and Rust. Nim has a very small community, and almost nobody is hiring for Nim experience. Going through Nim's forum, I think most developers tend to work on Nim projects alone. If marketability is your priority, learn the popular languages like java, c, c++, golang etc. Even people hiring Rust developers usually have some leeway to hire someone who can learn Rust on the job. The decision to learn a programming language comes down to three options: - Popularity - You are paid to learn - You are passionate about it, and you don't expect to collaborate with anyone. Number 3 is the reason why I am learning Nim.
- deleted 4y ago
  [deleted]
- rich_sasha 4y ago
  I think you are jumping to conclusions about my choices. Why do you explain to me how to decide when you don't know my objectives and constraints? My main language is Python, to that I'd like to add a compiled, native code, fast-ish, statically typed language with good Python interop. That takes away JVM and .net languages and leaves, roughly, C++, Rust, Nim, maybe Go. I take Go off because I don't like it. I also can't stand modern C++. What does it leave me with?
  - anyfactor 4y ago
    > Why do you explain to me how to decide when you don't know my objectives and constraints? You asked a question. You didn't provide any context. I took the initiative to answer the question based on the mere statement of "Nim vs Rust". My intial feedback still holds true. Does your job require you to learn anything specific or do you want to learn anything just because? > I take Go off because I don't like it. I also can't stand modern C++. You are giving your personal opinion and without context. Why do you not like Go.... never mind. It is the weekend, try Nim and Rust both, see what you like.

I'm choosing between learning Nim or Rust. Nim frankly looks like the nicer of the two, but also less marketable and with smaller community. Suck to say but it's true.

PixyMisa 4y ago

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.

tomrod 4y ago
Does Nim have any large groups sponsoring? Part of the appeal of Rust is that it will be around in 20 years due to so many groups adopting it and maturing its governance. 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.
- sigzero 4y ago
  https://nim-lang.org/sponsors.html https://nim-lang.org/sponsors.html
  - tomrod 4y ago
    Ah, so its definitely a passion project with only about $21k in direct funding per month as of last update (2019). Hey @G/Xooglers, Linux Foundation, etc., consider supporting Nim!
memco 4y ago
I had a similar experience. I took a very small project from Python and turned it into Nim: it was about six times as fast to run and took roughly the same amount of code in both. I have plans to learn more but this article is actually a little more fuel for my fire as I think one of my next explorations would be transferring and running code on other systems. If portability is as easy I could see this being used for some work tools I am building. We will almost surely never replace the current language all the major code is written in, but for small self-contained tools it would be great.
bitexploder 4y ago
Something I long assumed about Rust before really getting started is that it is /slower/ to develop with. And at first that is definitely true because it introduces some pretty big, powerful, and constraining things. When you learn to work with these things and have taken your lumps discussing your code with `rustc` it is a lot of fun. 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.
- syntheweave 4y ago
  Rust's sphere of necessary domain knowledge is higher than average. That's not a downside relative to the goal it has in mind, but it is a trade-off. When you're an indie developer working on a side project, there's a strong impulse to let go of a lot of the specific quality controls and customizations that you can use in a team setting where you're paid to know how to operate the inner workings, and instead look for something that is "prosumer" and lets you hack out a solution. 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.
_dain_ 4y ago
I'm learning Rust now, I can say Nim is much harder. Maybe the language itself is simpler, but the documentation is just not very good. Very unpolished and amateurish. I actually forked out fifty quid for Araq's "Mastering Nim" book; it is atrocious. Spelling and grammatical errors on every page. The very first code example did not compile. 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.
- planetis 4y ago
  I have the book, and it's an excellent resource for the language. I might be a little biased because I am a long time Nim user but definitely so are you.
- winrid 4y ago
  Yeah, I wrote an equivalent service in Java and Nim, and I just couldn't get Nim to perform as well as Java, and it wasn't even easy to write. Random segfaults, depending on memory manager used, random libraries requiring different memory managers, ORC being talked about a lot despite causing random segfaults, and so on. I really want to love Nim.
  - lenkite 4y ago
    Author's take on Java is really funny. "..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.
    - wiseowise 4y ago
      Not only Java, but major JVM languages as well (Clojure, Kotlin, Scala).
epage 4y ago
> Nim is also easier to learn - if you know Python and any conventional statically typed language, it's a walk in the park. I 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.

anyfactor 4y ago

I honestly don't think your options should be between Nim and Rust. Nim has a very small community, and almost nobody is hiring for Nim experience. Going through Nim's forum, I think most developers tend to work on Nim projects alone. If marketability is your priority, learn the popular languages like java, c, c++, golang etc. Even people hiring Rust developers usually have some leeway to hire someone who can learn Rust on the job. The decision to learn a programming language comes down to three options: - Popularity - You are paid to learn - You are passionate about it, and you don't expect to collaborate with anyone. Number 3 is the reason why I am learning Nim.

deleted 4y ago
[deleted]
rich_sasha 4y ago
I think you are jumping to conclusions about my choices. Why do you explain to me how to decide when you don't know my objectives and constraints? My main language is Python, to that I'd like to add a compiled, native code, fast-ish, statically typed language with good Python interop. That takes away JVM and .net languages and leaves, roughly, C++, Rust, Nim, maybe Go. I take Go off because I don't like it. I also can't stand modern C++. What does it leave me with?
- anyfactor 4y ago
  > Why do you explain to me how to decide when you don't know my objectives and constraints? You asked a question. You didn't provide any context. I took the initiative to answer the question based on the mere statement of "Nim vs Rust". My intial feedback still holds true. Does your job require you to learn anything specific or do you want to learn anything just because? > I take Go off because I don't like it. I also can't stand modern C++. You are giving your personal opinion and without context. Why do you not like Go.... never mind. It is the weekend, try Nim and Rust both, see what you like.