3 ms·

Anyone here used Nim for a bigger project? What was your experience like?

girvo 4y ago
https://news.ycombinator.com/item?id=33287817 https://news.ycombinator.com/item?id=33287817 You bet I have! What would you like to know beyond that comment?
- generichuman 4y ago
  What's your debugging experience like? i.e. The tools you use, do you have to debug the C output, etc.
  - girvo 4y ago
    Because I live in embedded land, I use the compileOnly C output. What’s really nice about that though is with debugger:native enabled, it embeds source-map comments in the C back to the Nim lines they tie to! All in VSCode with gdb (and OpenOCD). This gives me full interactive debugging, breakpoints etc of the Nim source directly — including via a JTAG from the ESP32 itself :) it’s super nice, considering none of the tools internally were built for Nim haha. The #Line macro is surprisingly powerful in C debugging land it turns out If you’re doing desktop/non embedded stuff it’s even easier, and you can also enable useMalloc and run Nim programs through the Valgrind suite easily
pietroppeter 4y ago
see also this talk by Mamy (taken from last year nim conf) to see the experience of using it in production in status (main sponsor of nim): https://www.youtube.com/watch?v=5wljNaPkU7M&list=PLxLdEZg8DRwRXNrY7yyGU0-g_GRSyRGKo&index=8 https://www.youtube.com/watch?v=5wljNaPkU7M&list=PLxLdEZg8DR...
ThomasTJdev 4y ago
We use it at www.cxplanner.com for a mix of micro/mono-services. Statically typed and good compile time combined with really fast code makes Nim perfect for us.
- Cwizard 4y ago
  Could you elaborate why you chose Nim over other languages? The advantages need to be pretty strong when picking a niche language like this I would assume? Curious what the thought process was like.
  - girvo 4y ago
    While I work somewhere different, the choice basically came down to C/C++, or Nim (which compiles to either, and gives us the simplest binding story out there for handling external libraries and tools that our project requires). Zig and Rust of course both exist, as does TinyGo, but Zig’s embedded story isn’t anywhere near complete yet, Rust is closer but it’s tendency to rewrite the embedded world from scratch (which is great for safety! Just bad for rapid firmware dev when we have a whole host of vendor drivers we need to use that aren’t supported in Rust’s embedded story yet) make them a pain TinyGo was genuinely considered, but using a not-quite-normal compiler gave me the willies — which turned out to be a good choice as we have a lot of code sharing between the firmware and the server that it talks to (with a custom message protocol over TCP that’s encrypted — libsodium is great). The long and the short of it for us was: do we want to write C/C++? Not really, it’s a pain to hire for and a pain to teach. And right now, Nim is a good slot in replacement/addition. Early on in the project we wrote C libs to encapsulate some C driver code, and exposed that to Nim — and slowly migrated it all to Nim directly. Now it’s just ESP-IDF with Nim on top, no custom C code at all!

https://news.ycombinator.com/item?id=33287817 https://news.ycombinator.com/item?id=33287817 You bet I have! What would you like to know beyond that comment?

generichuman 4y ago
What's your debugging experience like? i.e. The tools you use, do you have to debug the C output, etc.
- girvo 4y ago
  Because I live in embedded land, I use the compileOnly C output. What’s really nice about that though is with debugger:native enabled, it embeds source-map comments in the C back to the Nim lines they tie to! All in VSCode with gdb (and OpenOCD). This gives me full interactive debugging, breakpoints etc of the Nim source directly — including via a JTAG from the ESP32 itself :) it’s super nice, considering none of the tools internally were built for Nim haha. The #Line macro is surprisingly powerful in C debugging land it turns out If you’re doing desktop/non embedded stuff it’s even easier, and you can also enable useMalloc and run Nim programs through the Valgrind suite easily

pietroppeter 4y ago

see also this talk by Mamy (taken from last year nim conf) to see the experience of using it in production in status (main sponsor of nim): https://www.youtube.com/watch?v=5wljNaPkU7M&list=PLxLdEZg8DRwRXNrY7yyGU0-g_GRSyRGKo&index=8 https://www.youtube.com/watch?v=5wljNaPkU7M&list=PLxLdEZg8DR...

ThomasTJdev 4y ago

We use it at www.cxplanner.com for a mix of micro/mono-services. Statically typed and good compile time combined with really fast code makes Nim perfect for us.

Cwizard 4y ago
Could you elaborate why you chose Nim over other languages? The advantages need to be pretty strong when picking a niche language like this I would assume? Curious what the thought process was like.
- girvo 4y ago
  While I work somewhere different, the choice basically came down to C/C++, or Nim (which compiles to either, and gives us the simplest binding story out there for handling external libraries and tools that our project requires). Zig and Rust of course both exist, as does TinyGo, but Zig’s embedded story isn’t anywhere near complete yet, Rust is closer but it’s tendency to rewrite the embedded world from scratch (which is great for safety! Just bad for rapid firmware dev when we have a whole host of vendor drivers we need to use that aren’t supported in Rust’s embedded story yet) make them a pain TinyGo was genuinely considered, but using a not-quite-normal compiler gave me the willies — which turned out to be a good choice as we have a lot of code sharing between the firmware and the server that it talks to (with a custom message protocol over TCP that’s encrypted — libsodium is great). The long and the short of it for us was: do we want to write C/C++? Not really, it’s a pain to hire for and a pain to teach. And right now, Nim is a good slot in replacement/addition. Early on in the project we wrote C libs to encapsulate some C driver code, and exposed that to Nim — and slowly migrated it all to Nim directly. Now it’s just ESP-IDF with Nim on top, no custom C code at all!