9 ms·

In what cases is Nim a better option than Rust? Would be great if anyone with more experience can share more information.

jononor 6y ago
The relative simplicity of the language is a feature. I can imagine introducing Nim to embedded/microcontroller firmware developers that only know/use C99 now. I cannot imagine introducing Rust - while a great language, it is C++ level complexity - and that is not always warranted.
- elcritch 6y ago
  Nim fits great on microcontrollers! Benefit is that it compiles to C and therefore can run anywhere C can. It also lets you reuse all the rest of the embedded C environment and build tools, which given the nature of embedded toolchains is handy for hitting the ground running. Rust's standard library/runtime binaries are really heavy compared to Nim's.
  - weitzj 6y ago
    How are your esp32 Nim deployments holding up? Do you have futur plans for the new esp32 riscv processors?
    - elcritch 6y ago
      > How are your esp32 Nim deployments holding up? They're doing great! Nim has proven surprisingly stable, which was a fear I had at first. The core team has improved compiler support and I've not run into any issues updating so far. It bolster's my confidence in Nim. Even if Nim development were to suddenly "stop" tomorrow, it'd easily be useable for embedded for a decade or more. There's improvement to be made in Nim, but it's a resilient system design. If the same were to happen to Rust or Crystal, for example, you'd have issues keeping the compiler up to date with LLVM, etc. Compiling to C gives a lot of stability for embedded work. Sort of similar to how Delphi Pascal is still useable today. One surprise came when I had to do some optimizations and went from `-d:debug` to `-d:release`. The debug code added enough overhead it fixed some timing issues with the high end ADC we're using. Moving to release mode made it too fast and required adding the required delay (it was in the ADC datasheet but forgot it). Easy to solve, but it's worth noting. > Do you have futur plans for the new esp32 riscv processors? If a risc-v processor supports C, then it already supports Nim! The real question is libraries and/or build support for the target. An afternoon of work can get the Nim build setup to work with almost any C/C++ build system. Really, Nim on risc-v just requires a target board and someone to sit down for a few hours. It's a fun "hacking exercise" :-) As a side tangent, I'd like to make a first class "pure" FreeRTOS library as it's the most widely used RTOS. That's after dealing with a lot of annoying race conditions in the `esp-idf` and seeing the incredible amount of hacky C code in embedded systems. Building on FreeRTOS but introducing esp32-like libraries for vfat/files/networking/etc that'd work across microcontrollers would make for an incredibly productive environment (for embedded work). There's also the possibility of using DrNim [1] to add formal verification for certain algorithms! Nim's effect system is very flexible. Really useful would be using the "guards and locks" [2] to write and prevent deadlocks (and maybe avoid locks?) when writing resource management and device drivers. A lot of the esp-idf issue I've run into are race conditions or slow speed since even `echo`/`printf` must have a lock to protect the system UART. Those are open questions/problems, and I'm starting a new job next month so it depends on what the needs there end up being. 1: https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html 2: https://nim-lang.org/docs/manual_experimental.html#guards-and-locks https://nim-lang.org/docs/manual_experimental.html#guards-an...
      - federico_c 6y ago
        Nim natively supports 64bit RISC-V since years and 32bit in the current devel. Also, the compiler itself is built for rv64 in Debian.
      - weitzj 6y ago
        That’s very insightful. Thank you. Some more questions since you are the person which shows up for esp32 and nim in the whole wide world :) Did you try out the esp-idf 4.3 release yet? I think you mentioned somewhere to not use 4.2. but 4.3 gives you the esp-managed Mqtt service on Aws (rainmaker) Do you have any thoughts on Freertos vs Zephyr whilst using Nim?
        elcritch 6y ago
        > That’s very insightful. Thank you. Some more questions since you are the person which shows up for esp32 and nim in the whole wide world :) You're welcome. lol, no one else did it so there you are. > Did you try out the esp-idf 4.3 release yet? No, my work requires stability so I haven't tried any of the new esp-idf releases. Nesper does compile with 4.2 if you pass the flag for it, but it's not well tested. If none of the major API's have changed 4.3 should work. It would be good to wrap the mqtt aws service. Don't know if I'll have time for it though. But it's really not too hard to wrap using `c2nim` on the header files. PR's welcome! :-) > Do you have any thoughts on Freertos vs Zephyr whilst using Nim? I would like to try Zephyr sometime. FreeRTOS is used by AWS and the esp32 so it seemed a good start.
planetis 6y ago
For me, it's a full stack language, write the frontent with karax https://github.com/pragmagic/karax https://github.com/pragmagic/karax or react bindings https://github.com/kristianmandrup/react-16.nim https://github.com/kristianmandrup/react-16.nim and backend in pure nim with any of the available web frameworks (jester/prologue/looper) and orms (ormin/norm) and share code and type declaration between the two.
- andybak 6y ago
  How does karax run Nim client side? Cross compile to js or a wasm blob? Or something else entirely?
  - planetis 6y ago
    Nim compiles to js with `nim js source`. I'm not familiar with wasm but it's also possible, know people who have done that.
  - shirleyquirk 6y ago
    Nim compiles to js (as well as c and c++)
    - magicalhippo 6y ago
      How much of C and the standard library does it use? Like, if I wanted to make my own C compiler, how much would I have to implement for it to be usable with Nim-generated code? Does it use a fairly constrained subset or does it use a lot of C and the standard library? I imagine the latter but just curious.
      - cb321 6y ago
        Well, it works with TinyCC/tcc where you can get order 200 millisecond compiles. While tcc does do most of c99, I do not think Nim requires anything past c89. libc-wise, it doesn't use even all of standard C. Minimal stdio/string stuff. You can easily access any C libs, though. So, a given program may have more dependency, but that is up to you (or to your Nim package deps). Full disclosure, not everything works - different backends tend to have slightly different bugs/coverage, but this also applies to c++ and js backends. But I use tcc as my default backend (in my nim.cfg file) every day and only run into problems like a time or two per year.
suncore 6y ago
I think the main difference (benefit?) is that Nim has the convenience of a garbage collected language while retaining good and predictable performance (e.g. via ARC/ORC and thread-local GC). Rust has no GC so requires more from the programmer. Personally, I'd rather use a GC language to have less complexity in the code even though I have to spend some more time learning to use the GC correctly.
- Rompect 6y ago
  For normal purposes, dealing with Rust's lifetimes will be easier than spending some time "learning to use the GC correctly"
  - pjmlp 6y ago
    Not writing GUIs in Rust are we?
    - k__ 6y ago
      High level Rust libraries like Yew are pretty straight forward to use.
      - pjmlp 6y ago
        When the GUI is actually the browser in HTML DOM and JS, with GC.
        k__ 6y ago
        Fair point, haha.
  - dom96 6y ago
    What do you consider "normal" and "non-normal"?
  - Symmetry 6y ago
    It really depends on what you're doing. If you've developing an OS or web browser or game engine you're going to be having to think about memory management very carefully in any event and dealing with Rust's lifetimes is just formalizing the work you'd be doing anyways. But most applications aren't optimized that heavily and as long as you don't have a memory leak or an algorithmic pessimization you don't have to worry about performance in most cases and having a garbage collector is saving you a lot of work.
logicchains 6y ago
Nim compiles way faster, which can be a huge boost to productivity. It's also a lot easier to metaprogram in Nim
johnisgood 6y ago
I consider Nim to be a compiled, faster Python. Nim is very easy to read and understand, and prototype in, vs. Rust.
- beagle3 6y ago
  Nim looks Pytonish (and has some Python-inspired syntax), but it is very much NOT Python. People coming from Python that expect a "compiled, faster" Python often find a compiled, faster language but have very weird concepts expecting that language to behave like Python though it isn't.
  - macleginn 6y ago
    When I started learning Nim, I did not really expect anything, but time and again I caught myself thinking, ‘This is so much like Python!’ Eventually I lost interest because I do not need a faster Python that is not Python, and I didn’t find much else to be enthusiastic about.
    - matthiaswh 6y ago
      I've written a large-ish amount of Nim code on personal projects while using Python day to day at work, and almost every time I'm working with Nim my brain is screaming at me at how unlike Python it is. Nim took some inspiration from Python's syntax, but the similarity is only skin deep. The construct of the language is very, very different resulting in code that usually looks and is structured differently. IMO going into Nim thinking it will be like Python but compiled! and faster! with types! is not a good way to approach it. It is an entirely different language altogether.
      - rattray 6y ago
        I'm curious - how would you describe the qualitative differences in code structure that results? Are there ways in which Nim nudges you to structure your code in better ways than you would in Python? Are there footguns?
pjmlp 6y ago
Most of them actually, it is only lacking in manpower. It provides the productivity of having a GC around (no need with coding for borrow checker patterns), you can still go as low level as you want, including writing GC free code, and is very fast compiling code.
deleted 6y ago
[deleted]
the__alchemist 6y ago
This is subjective, but I prefer Nim's python-like scoping syntax; ie no semilonons nor curlybraces. Someone else in this thread posted a comment to the opposite effect! That said, I don't see a compelling class of projects to use it on instead of Rust. I'll consider Nim next time I'm looking at making a python project. However - most of the times this happens is if I'm making a web backend or doing something numerical, where Python has a library advantage.
- GordonS 6y ago
  Funny how personal preference with regard to some syntax is so polarising - I'm coming from a primarily C# background and while Nim looks interesting, I find the lack of semicolon line endings and the whitespace-based scopes, to be really off-putting!
  - cb321 6y ago
    Syntactic indentation has been very polarizing since at least Python 0.9 (and maybe others) in the late 80s. Like ()s in Nim, Haskell also has a "both brackets or whitespace" kind of vibe. But, yeah, choice lets different parts of code bases differ. No two ways around that. A ton of people had knee-jerk resistance to Python's lexical style but "got over it" eventually. There really is a lot more to Nim than just this (its generic/template/macro metaprogramming, user-defined operators, GC options, speed, etc.). Many, many things can be done as libraries that would require direct compiler support in other languages. I would encourage you to give it a try.
    - GordonS 6y ago
      > There really is a lot more to Nim than just this I've actually just been skimming some tutorials and docs, and wow, you're not wrong! I'm impressed - Nim seems to be rammed with features, but also easy to get started with (as long as you ignore some of the more advanced stuff). I've recently been trying to find time and motivation to start learning Rust, but I have to say that (even with horrible indentation syntax :p ) Nim looks really compelling too...

jononor 6y ago

The relative simplicity of the language is a feature. I can imagine introducing Nim to embedded/microcontroller firmware developers that only know/use C99 now. I cannot imagine introducing Rust - while a great language, it is C++ level complexity - and that is not always warranted.

elcritch 6y ago
Nim fits great on microcontrollers! Benefit is that it compiles to C and therefore can run anywhere C can. It also lets you reuse all the rest of the embedded C environment and build tools, which given the nature of embedded toolchains is handy for hitting the ground running. Rust's standard library/runtime binaries are really heavy compared to Nim's.
- weitzj 6y ago
  How are your esp32 Nim deployments holding up? Do you have futur plans for the new esp32 riscv processors?
  - elcritch 6y ago
    > How are your esp32 Nim deployments holding up? They're doing great! Nim has proven surprisingly stable, which was a fear I had at first. The core team has improved compiler support and I've not run into any issues updating so far. It bolster's my confidence in Nim. Even if Nim development were to suddenly "stop" tomorrow, it'd easily be useable for embedded for a decade or more. There's improvement to be made in Nim, but it's a resilient system design. If the same were to happen to Rust or Crystal, for example, you'd have issues keeping the compiler up to date with LLVM, etc. Compiling to C gives a lot of stability for embedded work. Sort of similar to how Delphi Pascal is still useable today. One surprise came when I had to do some optimizations and went from `-d:debug` to `-d:release`. The debug code added enough overhead it fixed some timing issues with the high end ADC we're using. Moving to release mode made it too fast and required adding the required delay (it was in the ADC datasheet but forgot it). Easy to solve, but it's worth noting. > Do you have futur plans for the new esp32 riscv processors? If a risc-v processor supports C, then it already supports Nim! The real question is libraries and/or build support for the target. An afternoon of work can get the Nim build setup to work with almost any C/C++ build system. Really, Nim on risc-v just requires a target board and someone to sit down for a few hours. It's a fun "hacking exercise" :-) As a side tangent, I'd like to make a first class "pure" FreeRTOS library as it's the most widely used RTOS. That's after dealing with a lot of annoying race conditions in the `esp-idf` and seeing the incredible amount of hacky C code in embedded systems. Building on FreeRTOS but introducing esp32-like libraries for vfat/files/networking/etc that'd work across microcontrollers would make for an incredibly productive environment (for embedded work). There's also the possibility of using DrNim [1] to add formal verification for certain algorithms! Nim's effect system is very flexible. Really useful would be using the "guards and locks" [2] to write and prevent deadlocks (and maybe avoid locks?) when writing resource management and device drivers. A lot of the esp-idf issue I've run into are race conditions or slow speed since even `echo`/`printf` must have a lock to protect the system UART. Those are open questions/problems, and I'm starting a new job next month so it depends on what the needs there end up being. 1: https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html 2: https://nim-lang.org/docs/manual_experimental.html#guards-and-locks https://nim-lang.org/docs/manual_experimental.html#guards-an...
    - federico_c 6y ago
      Nim natively supports 64bit RISC-V since years and 32bit in the current devel. Also, the compiler itself is built for rv64 in Debian.
    - weitzj 6y ago
      That’s very insightful. Thank you. Some more questions since you are the person which shows up for esp32 and nim in the whole wide world :) Did you try out the esp-idf 4.3 release yet? I think you mentioned somewhere to not use 4.2. but 4.3 gives you the esp-managed Mqtt service on Aws (rainmaker) Do you have any thoughts on Freertos vs Zephyr whilst using Nim?
      - elcritch 6y ago
        > That’s very insightful. Thank you. Some more questions since you are the person which shows up for esp32 and nim in the whole wide world :) You're welcome. lol, no one else did it so there you are. > Did you try out the esp-idf 4.3 release yet? No, my work requires stability so I haven't tried any of the new esp-idf releases. Nesper does compile with 4.2 if you pass the flag for it, but it's not well tested. If none of the major API's have changed 4.3 should work. It would be good to wrap the mqtt aws service. Don't know if I'll have time for it though. But it's really not too hard to wrap using `c2nim` on the header files. PR's welcome! :-) > Do you have any thoughts on Freertos vs Zephyr whilst using Nim? I would like to try Zephyr sometime. FreeRTOS is used by AWS and the esp32 so it seemed a good start.

planetis 6y ago

For me, it's a full stack language, write the frontent with karax https://github.com/pragmagic/karax https://github.com/pragmagic/karax or react bindings https://github.com/kristianmandrup/react-16.nim https://github.com/kristianmandrup/react-16.nim and backend in pure nim with any of the available web frameworks (jester/prologue/looper) and orms (ormin/norm) and share code and type declaration between the two.

andybak 6y ago
How does karax run Nim client side? Cross compile to js or a wasm blob? Or something else entirely?
- planetis 6y ago
  Nim compiles to js with `nim js source`. I'm not familiar with wasm but it's also possible, know people who have done that.
- shirleyquirk 6y ago
  Nim compiles to js (as well as c and c++)
  - magicalhippo 6y ago
    How much of C and the standard library does it use? Like, if I wanted to make my own C compiler, how much would I have to implement for it to be usable with Nim-generated code? Does it use a fairly constrained subset or does it use a lot of C and the standard library? I imagine the latter but just curious.
    - cb321 6y ago
      Well, it works with TinyCC/tcc where you can get order 200 millisecond compiles. While tcc does do most of c99, I do not think Nim requires anything past c89. libc-wise, it doesn't use even all of standard C. Minimal stdio/string stuff. You can easily access any C libs, though. So, a given program may have more dependency, but that is up to you (or to your Nim package deps). Full disclosure, not everything works - different backends tend to have slightly different bugs/coverage, but this also applies to c++ and js backends. But I use tcc as my default backend (in my nim.cfg file) every day and only run into problems like a time or two per year.

suncore 6y ago

I think the main difference (benefit?) is that Nim has the convenience of a garbage collected language while retaining good and predictable performance (e.g. via ARC/ORC and thread-local GC). Rust has no GC so requires more from the programmer. Personally, I'd rather use a GC language to have less complexity in the code even though I have to spend some more time learning to use the GC correctly.

Rompect 6y ago
For normal purposes, dealing with Rust's lifetimes will be easier than spending some time "learning to use the GC correctly"
- pjmlp 6y ago
  Not writing GUIs in Rust are we?
  - k__ 6y ago
    High level Rust libraries like Yew are pretty straight forward to use.
    - pjmlp 6y ago
      When the GUI is actually the browser in HTML DOM and JS, with GC.
      - k__ 6y ago
        Fair point, haha.
- dom96 6y ago
  What do you consider "normal" and "non-normal"?
- Symmetry 6y ago
  It really depends on what you're doing. If you've developing an OS or web browser or game engine you're going to be having to think about memory management very carefully in any event and dealing with Rust's lifetimes is just formalizing the work you'd be doing anyways. But most applications aren't optimized that heavily and as long as you don't have a memory leak or an algorithmic pessimization you don't have to worry about performance in most cases and having a garbage collector is saving you a lot of work.

logicchains 6y ago

Nim compiles way faster, which can be a huge boost to productivity. It's also a lot easier to metaprogram in Nim

johnisgood 6y ago

I consider Nim to be a compiled, faster Python. Nim is very easy to read and understand, and prototype in, vs. Rust.

beagle3 6y ago
Nim looks Pytonish (and has some Python-inspired syntax), but it is very much NOT Python. People coming from Python that expect a "compiled, faster" Python often find a compiled, faster language but have very weird concepts expecting that language to behave like Python though it isn't.
- macleginn 6y ago
  When I started learning Nim, I did not really expect anything, but time and again I caught myself thinking, ‘This is so much like Python!’ Eventually I lost interest because I do not need a faster Python that is not Python, and I didn’t find much else to be enthusiastic about.
  - matthiaswh 6y ago
    I've written a large-ish amount of Nim code on personal projects while using Python day to day at work, and almost every time I'm working with Nim my brain is screaming at me at how unlike Python it is. Nim took some inspiration from Python's syntax, but the similarity is only skin deep. The construct of the language is very, very different resulting in code that usually looks and is structured differently. IMO going into Nim thinking it will be like Python but compiled! and faster! with types! is not a good way to approach it. It is an entirely different language altogether.
    - rattray 6y ago
      I'm curious - how would you describe the qualitative differences in code structure that results? Are there ways in which Nim nudges you to structure your code in better ways than you would in Python? Are there footguns?

pjmlp 6y ago

Most of them actually, it is only lacking in manpower. It provides the productivity of having a GC around (no need with coding for borrow checker patterns), you can still go as low level as you want, including writing GC free code, and is very fast compiling code.

deleted 6y ago

[deleted]

the__alchemist 6y ago

This is subjective, but I prefer Nim's python-like scoping syntax; ie no semilonons nor curlybraces. Someone else in this thread posted a comment to the opposite effect! That said, I don't see a compelling class of projects to use it on instead of Rust. I'll consider Nim next time I'm looking at making a python project. However - most of the times this happens is if I'm making a web backend or doing something numerical, where Python has a library advantage.

GordonS 6y ago
Funny how personal preference with regard to some syntax is so polarising - I'm coming from a primarily C# background and while Nim looks interesting, I find the lack of semicolon line endings and the whitespace-based scopes, to be really off-putting!
- cb321 6y ago
  Syntactic indentation has been very polarizing since at least Python 0.9 (and maybe others) in the late 80s. Like ()s in Nim, Haskell also has a "both brackets or whitespace" kind of vibe. But, yeah, choice lets different parts of code bases differ. No two ways around that. A ton of people had knee-jerk resistance to Python's lexical style but "got over it" eventually. There really is a lot more to Nim than just this (its generic/template/macro metaprogramming, user-defined operators, GC options, speed, etc.). Many, many things can be done as libraries that would require direct compiler support in other languages. I would encourage you to give it a try.
  - GordonS 6y ago
    > There really is a lot more to Nim than just this I've actually just been skimming some tutorials and docs, and wow, you're not wrong! I'm impressed - Nim seems to be rammed with features, but also easy to get started with (as long as you ignore some of the more advanced stuff). I've recently been trying to find time and motivation to start learning Rust, but I have to say that (even with horrible indentation syntax :p ) Nim looks really compelling too...