I use Nim at work for embedded firmware development right now, and we evaluated Zig but it was a year and a half ago when we started the project, Zig just wasn’t as far along as it is now.

I’m currently in the process of writing a nice HAL/dev framework agnostic FreeRTOS binding in Nim, which maybe you’ll find useful once we can post it?

Do neither of these languages have better concurrency tools than porting FreeRTOS?

iirc the os needs to have processor specific task switching code in assembly, Freertos must have tons of ports already. Nim supposedly has nice FFI for C. The niceness of freertos is then mostly about it's.. system call design. If it's good, then you could probably progressively rewrite freertos in nim.

Never used nim and been a while since I did any embedded.

OS is not the same level of abstraction as a language.

This is an active problem in embedded. Cheap microcontrollers can have multiple cores that are not even the same architecture.

This means that just to get "blinky" running, you need to choose a (language, OS) tuple. And, given that "language" is generally "C", that means that your abstraction choices for OS are lousy.

Side question: last I checked, FreeRTOS didn't do a great job when multiple microcontrollers were involved--especially if the communication channels or synchronization were hardware-based. Has this changed?

FreeRTOS gives much more than just concurrency!

Like any time you get off the beaten path, there are rough patches, but to paraphrase another comment in this thread "Nim is just C", so anything that felt a little awkward just meant using an `importc` pragma and doing whatever I needed to do in an environment I felt more comfortable (you can also have C code compiled with a {.compile: "foo.c"} pragma, so if a module required something be done in C, you didn't have to monkey about with the build system to include it, it 'just worked')

The biggest negative I ever hit was that early on, Nim didn't have support for `volatile`, which meant it was a non-starter for doing anything with MMIO (I ended up being the one who added volatileLoad/volatileStore to Nim's stdlib so I could use it on a Cortex-M without having to drop into C so much).

For the most part though, if you're reasonably comfortable with embedded toolchains (i.e. you understand how to write linker scripts, understand what happens between a reset and actually getting into `main()`, etc), it's not much of a hurdle to set up a simple build system to compile your Nim code to C, link appropriately, and then sort of forget about it.

It's been a while, but IIRC I also got step-through debugging working with OpenOCD by having the nim compiler generate `#line` pragmas and including debug symbols, which was pretty neat.

This was all pre ARC/ORC, so I did have to make sure to be careful not to use ref objects, but ultimately it felt pretty seamless. I still tend towards fully manually managed memory on embedded projects, but I'd be curious to give it a go.