Please explain how you're going to GC on an 8bit microcontroller, or even an AMD64 when the bios/EFI passes control to you. GC requires a runtime; something needs to provide that runtime.
(JavaChips were interesting, thought iirc it only ran a certain subset of Java?)
That is interesting! Thanks! They seem to just be running the vm on PIC, though, not a straight compile. I wonder how well that works out in terms of resource utilization.
AVR seems to be... in progress. But if we're discussing the inherent properties of a language, not just what happens to be implemented today, the point is whether it's possible with reasonable overhead (e.g. performance, no weird emulation).
in C you're writing allocators without using malloc(), a part of the stdlib defined in the language spec. doesn't really feel qualitatively different to write Go without GC allocation. i guess it's more work but it's also not a showstopper that should decide whether Go is a systems programming lang or isn't. i mean it's not like we're talking about writing the Ruby runtime in Ruby here.
advantages of writing the Go runtime in Go might include, just spitballing here, avoiding ffi cost for runtime calls, enabling better optimizations around/into runtime calls, simplifying the build process, or even just enabling Go enthusiasts to contribute to the runtime without learning C. talking about actual language features, i think I'd almost be tempted over just by Go having a module system, but there's probaby a few other subjective ergonomic benefits that you can use without falling into the GC requirement. I'm not sure what exactly decided it for them, maybe i should look that up.
there's probably gonna be some OS-level non-Go shims written in either C or assembly or the weird Go way to write assembly but i feel that's fair as C-written runtimes probably need to have at least some inline asm somewhere as well.
(JavaChips were interesting, thought iirc it only ran a certain subset of Java?)