Hacker News Reader

Comment by hikarudo | Hacker News Reader

I'm considering using Nim for an embedded project, because Nim can generate C or C++ code, and a C and C++ compiler is all there is for my target platform (a DSP).

I would like to use C++11, but the manufacturer only supports C++03, and will never add support for C++11 because it's a legacy DSP.

View on HN

Sounds like Nim would be perfect for your use case. Happy to help out if you run into any problems.

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?

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.

Thanks!

How would I go about wrapping OpenCV's C++ API?

Here is a C++ wrapper for SFML that I made, you can use it as an example: https://github.com/dom96/nim-in-action-code/tree/master/Chap...

You can also try using `c2nim`'s cpp mode.

Oh wow. That looks so frictionless, thanks for sharing the example!

Reply on news.ycombinator.com