5 ms·
AFAIK Go has a GC you can't avoid, so it's not very suitable for embedded or realtime.
by wolf550e 6y ago
AFAIK Go has a GC you can't avoid, so it's not very suitable for embedded or realtime.
- deleted 6y ago[deleted]
- coder543 6y ago"not very suitable" is a relative term. TinyGo is a cool project: https://tinygo.org https://tinygo.org There are various conference presentations about it that show it in action.
- IshKebab 6y agoCool project but I think he's still right - you normally don't want GC on your microcontroller and often you don't want heap allocations at all. Very difficult to write Go with those constraints.
- coder543 6y agoLots of "serious" microcontroller projects are written in MicroPython, Lua (such as eLua), and Espruino (JavaScript). I think it's simply an outdated oversimplification in 2021 to say that microcontroller projects "normally" don't want heap allocations at all. TinyGo also makes it relatively easy to avoid heap allocations because you can change a compiler flag to make heap allocations a compiler error^1, if that's required for a particular project. ^1: https://tinygo.org/usage/important-options/ https://tinygo.org/usage/important-options/ (look at -gc=none) Another interesting link: https://tinygo.org/compiler-internals/heap-allocation/ https://tinygo.org/compiler-internals/heap-allocation/
- Cyph0n 6y agoIt ultimately depends on your definition of “serious” and the microcontrollers we’re talking about. For performance-sensitive areas where deterministic latency is critical, a GC simply won’t cut it, even if you can control when to run the GC step. For lower end microcontrollers, I highly doubt any of those solutions would ever work: there is simply too much “magic” (read: overhead) involved. This is primarily why C is still king of the microcontroller world.