Hacker News

points by ted_dunning 10 hours ago | 0 comments

Embedded systems benefit substantially from decreased GC, especially in the context of non-relocating collectors (as with Go) in machines without memory management units. The problem is not the overhead, it is the effect of memory fragmentation.

The OP article here is nice because it allows selective enforcement of allocation free code. If you have code that has some discipline about heap allocation such as having all small allocations then you are OK on the fragmentation front.

[–] bootsmann 9 hours ago

Isn’t writing Go for embedded systems kinda like eating soup with a fork tho? This language was designed to write multithreaded asynchronous code to power microservice meshes.

[–] Groxx 7 hours ago

If it's within like 90% of your targets and it's a far easier development experience, but you need to optimize a small bit to fit in the budget, tools like this can be fantastically useful. Rewriting the whole thing in, like, C, complete with a coroutine stack, would be a hell of a lot more work than "avoid allocations here".

[–] pjmlp 9 hours ago

Real time Java is doing just fine with PTC and Aicas still in business.

[–] fpoling 7 hours ago

GC in Java is the best in world with a lot options and knobs that allows to tune to particular application requirements. Still some trading platforms using it disable GC and just ensure enough memory is available so memory leaks during the trading hours would not matter before the application will be restarted.

[–] pjmlp 5 hours ago

Just like plenty of C and C++ deployment scenarios have special purpose memory allocators, or forbid memory allocations other than at startup.

Yet one still needs to account with processes like MISRA to account for safety.