Hacker News Reader

Comment by eaurouge | Hacker News Reader

I bought your book with the hopes that you would include a chapter on embedded programming, but was disappointed to find it barely got a mention in the book. I remember an earlier discussion here where you were considering and it seemed like a real possibility.

Unfortunately, I haven't been able to find recent (ideally official) documentation/discussion on embedded programming. Contrast this with Rust where there's a significant focus on embedded bare metal, particularly for Cortex-M MCUs. With the recently announced support from Status, are there any plans to provide more support for embedded bare metal?

View on HN

Support for embedded is indeed getting into focus. I hope to release an article soon how the '--gc:regions' switch works (which is misnamed, it's a way to do memory management, not a GC...) and in the longer run the destructor-based runtime will ensure that memory is freed sooner than a GC would for memory constrained devices.

Having said that, "embedded" is a wide field and sometimes one cannot even afford a heap, no matter if garbage collected or managed manually. But even then Nim can be used, you still get array bounds checking, Ada-inspired strong type checking plus the meta programming goodies.

Great! My interest is in bare metal environments where you typically don't use a heap. I'm not familiar with the `--gc:regions` switch, but I think a good start could be a guide on how to implement simple non-garbage collected programs.

That's region-based memory management. ML guys tried it http://mlton.org/Regions

Looks like they concluded that having the compiler automatically choose an appropriate region but silently leak the memory when that fails doesn't work well? Kind of like GC by reference-counting without a cycle collector.

Couldn't the compiler just reject code that would need to allocate in the global region, unless the programmer explicitly annotates it to make it global? It says the SML type system is too weak for this, but perhaps Nim's type system is sufficient?

Yeah, sorry about that. The initial book plan had a chapter on embedded programming but it had to be cut because I exceeded the page count.

I made a promise that I would write an article about it as a replacement and I still intend to do that. It takes time of course and I personally don't have as much embedded programming experience as I would like right now, so it'll take me even more time. But it will happen :)

As far as plans for more support from Nim itself I don't think there are any specific plans right now. If you've got time and this is your passion then please consider starting contributing to Nim :)

That would be great if you do write an article. I would be happy to contribute, but I would really like to see some official discussion or documentation from the team first before moving forward.

Reply on news.ycombinator.com