9 ms·

There are roughly two orders of magnitude more microcontrollers in the world running code than application processors. GC is not acceptable on a microcontroller

by jack_h 2mo ago

There are roughly two orders of magnitude more microcontrollers in the world running code than application processors. GC is not acceptable on a microcontroller due to the extreme resource constraints. The GP post is correct, Go can replace some use cases for C, but it does not replace all use cases and GC is part of the reason.

throwaway894345 2mo ago
Go already runs on microcontrollers, but _just like C_, care must be taken to avoid using features that are not compatible with microcontrollers (such as dynamic memory).
deleted 2mo ago
[deleted]
win311fwg 2mo ago
> GC is not acceptable on a microcontroller due to the extreme resource constraints. Dynamic memory allocation on a microcontroller can be treacherous full stop, but if you have accepted the tradeoffs of using dynamic memory allocation then why not GC? You wouldn't want gc[1]-style GC, but there are other GC algorithms that can work well enough on micros. The Go spec calls for garbage collection, but it doesn't say how you have to collect garbage. > but it does not replace all use cases It could replace all use cases. There are arguably much better tools for many jobs[2], but if you had to the language isn't going to stop you. [1] gc the compiler, not GC garbage collection. Naming is the hardest problem in CS. [2] Some would say all jobs, but for the sake of discussion let's agree that Go can be a reasonable choice at least sometimes.
- loup-vaillant 2mo ago
  > * but if you have accepted the tradeoffs of using dynamic memory allocation then why not GC?* That’s the thing: many do not use dynamic allocation at all. Did you know for instance that you could write an entire modern cipher suite using only a small (<300 bytes), strictly bounded stack allocation? As for those who do use the "heap", many can do so with a strict stack discipline, so it’s not really a heap. Reason being, the environment has an extremely low call stack budget, so all bigger allocations happens in another stack, located in the heap. Then there are arenas, which are much simpler to implement than a general allocator, tend to have less overhead (both space and runtime) than malloc() or a GC, though I reckon they can still run out of space. Still, less treacherous than uncontrolled use of malloc(). Most of all though, even if the compiler can do mighty static region analysis to minimise heap usage and GC overhead, heck, even perhaps reduce it to absolutely zero in some cases, there’s still the problem of the programming interface: how does the programmer know about stuff like max heap usage? I guess the compiler could tell them, but then how do they fix it if usage exceeds the limit, or is unbounded? The wouldn’t be any clear link from heap usage to the source code, or it would be so diffuse it would be hard to determine where to begin. And of course, a GC’ed program would likely rely on many more pointers under the hood than one that manages its memory manually, which means significant space overhead even if the GC implementation itself is perfect. You want me to write something for an ESP-32, it’s gonna be in something like C, Rust, or Zig.
  - win311fwg 2mo ago
    > many do not use dynamic allocation at all. Exactly. You don’t need GC if you don’t produce garbage. And since Go uses stack-based memory like C you can avoid producing garbage just the same. And if you do need some kind of special memory allocation then you can do the same tricks you do with C. You still don’t have to use the built-in allocator. All the bellyaching about GC is silly because you don’t need it in the first place. The cries are like saying C isn’t suitable for microcontrollers because its standard library includes malloc… Just don’t use it. > You want me to write something for an ESP-32, it’s gonna be in something like C, Rust, or Zig. Sure. The Go creators were explicit that Go is designed for building network systems. That doesn’t mean it is impossible to use for anything else, but it was optimized for a particular niche. You will feel more comfortable using languages designed for microcontrollers when programming for microcontrollers. But it’s not GC you aren’t using that gets in the way. You don’t have to use every language feature just because it is there. Rust doesn’t become unusable for programming because it has a string type and you only need integers. Just don’t use it.
    - loup-vaillant 2mo ago
      "Just don’t use it" is a valid argument, if it’s clear when you’re using it or not. It’s easy not to use `malloc()`: just don’t call it, and don’t call dependencies that call it. Same for Rust’s string: don’t construct strings, and don’t depend on stuff that does. In some cases, avoiding heap allocation is just impossible. Take OCaml: last time I checked (over 10 years ago) there are two kinds of values: integers, and pointers to heap allocated objects. That’s basically it. Even floats are allocated on the heap (except when inside an array that’s the only optimisation). So unless you only do integer operations and avoid constructing any kind of data structure, you can’t avoid heap allocation. Other languages are much more conservative than OCaml in this regard. That with value types and all. If they’re clear enough which constructs don’t trigger heap allocation, and the set of thereof is rich enough to allow significant work, then yes "just don’t use the GC" is a valid option. Not all languages (I mean implementations, but we can conflate the two in most cases) fulfil those two conditions. Maybe Go does.
      - 2mo ago

by jack_h 2mo ago

throwaway894345 2mo ago

Go already runs on microcontrollers, but _just like C_, care must be taken to avoid using features that are not compatible with microcontrollers (such as dynamic memory).

deleted 2mo ago

[deleted]

win311fwg 2mo ago

> GC is not acceptable on a microcontroller due to the extreme resource constraints. Dynamic memory allocation on a microcontroller can be treacherous full stop, but if you have accepted the tradeoffs of using dynamic memory allocation then why not GC? You wouldn't want gc[1]-style GC, but there are other GC algorithms that can work well enough on micros. The Go spec calls for garbage collection, but it doesn't say how you have to collect garbage. > but it does not replace all use cases It could replace all use cases. There are arguably much better tools for many jobs[2], but if you had to the language isn't going to stop you. [1] gc the compiler, not GC garbage collection. Naming is the hardest problem in CS. [2] Some would say all jobs, but for the sake of discussion let's agree that Go can be a reasonable choice at least sometimes.

loup-vaillant 2mo ago
> * but if you have accepted the tradeoffs of using dynamic memory allocation then why not GC?* That’s the thing: many do not use dynamic allocation at all. Did you know for instance that you could write an entire modern cipher suite using only a small (<300 bytes), strictly bounded stack allocation? As for those who do use the "heap", many can do so with a strict stack discipline, so it’s not really a heap. Reason being, the environment has an extremely low call stack budget, so all bigger allocations happens in another stack, located in the heap. Then there are arenas, which are much simpler to implement than a general allocator, tend to have less overhead (both space and runtime) than malloc() or a GC, though I reckon they can still run out of space. Still, less treacherous than uncontrolled use of malloc(). Most of all though, even if the compiler can do mighty static region analysis to minimise heap usage and GC overhead, heck, even perhaps reduce it to absolutely zero in some cases, there’s still the problem of the programming interface: how does the programmer know about stuff like max heap usage? I guess the compiler could tell them, but then how do they fix it if usage exceeds the limit, or is unbounded? The wouldn’t be any clear link from heap usage to the source code, or it would be so diffuse it would be hard to determine where to begin. And of course, a GC’ed program would likely rely on many more pointers under the hood than one that manages its memory manually, which means significant space overhead even if the GC implementation itself is perfect. You want me to write something for an ESP-32, it’s gonna be in something like C, Rust, or Zig.
- win311fwg 2mo ago
  > many do not use dynamic allocation at all. Exactly. You don’t need GC if you don’t produce garbage. And since Go uses stack-based memory like C you can avoid producing garbage just the same. And if you do need some kind of special memory allocation then you can do the same tricks you do with C. You still don’t have to use the built-in allocator. All the bellyaching about GC is silly because you don’t need it in the first place. The cries are like saying C isn’t suitable for microcontrollers because its standard library includes malloc… Just don’t use it. > You want me to write something for an ESP-32, it’s gonna be in something like C, Rust, or Zig. Sure. The Go creators were explicit that Go is designed for building network systems. That doesn’t mean it is impossible to use for anything else, but it was optimized for a particular niche. You will feel more comfortable using languages designed for microcontrollers when programming for microcontrollers. But it’s not GC you aren’t using that gets in the way. You don’t have to use every language feature just because it is there. Rust doesn’t become unusable for programming because it has a string type and you only need integers. Just don’t use it.
  - loup-vaillant 2mo ago
    "Just don’t use it" is a valid argument, if it’s clear when you’re using it or not. It’s easy not to use `malloc()`: just don’t call it, and don’t call dependencies that call it. Same for Rust’s string: don’t construct strings, and don’t depend on stuff that does. In some cases, avoiding heap allocation is just impossible. Take OCaml: last time I checked (over 10 years ago) there are two kinds of values: integers, and pointers to heap allocated objects. That’s basically it. Even floats are allocated on the heap (except when inside an array that’s the only optimisation). So unless you only do integer operations and avoid constructing any kind of data structure, you can’t avoid heap allocation. Other languages are much more conservative than OCaml in this regard. That with value types and all. If they’re clear enough which constructs don’t trigger heap allocation, and the set of thereof is rich enough to allow significant work, then yes "just don’t use the GC" is a valid option. Not all languages (I mean implementations, but we can conflate the two in most cases) fulfil those two conditions. Maybe Go does.
    - 2mo ago