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!

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