4 ms·

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 ne

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?)

ben0x539 9y ago
What stops you from writing the runtime in the same language, just a subset of it that doesn't in turn depend on GC?
- jimktrains2 9y ago
  Because that subset of the language will often be different from the actual language.
- camus2 9y ago
  > What stops you from writing the runtime in the same language, just a subset of it that doesn't in turn depend on GC? At that point you'd better off using C or C++ directly. Go gives you absolutely no advantage, only costly abstractions.
  - ben0x539 9y ago
    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.
bjourne 9y ago
Which 8bit microcontrollers do Rust target?
- andrewflnr 9y ago
  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). High-level blog post: http://dylanmckay.io/blog/rust/avr/llvm/2017/02/09/safer-microcontrollers-almost-here.html http://dylanmckay.io/blog/rust/avr/llvm/2017/02/09/safer-mic... Tracking bug on GitHub: https://github.com/rust-lang/rust/issues/42450 https://github.com/rust-lang/rust/issues/42450
chenglou 9y ago
Fwiw OCaml is a GC language and can run on PIC: http://www.algo-prog.info/ocapic/web/index.php?id=ocapic http://www.algo-prog.info/ocapic/web/index.php?id=ocapic
- jimktrains2 9y ago
  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.

ben0x539 9y ago

What stops you from writing the runtime in the same language, just a subset of it that doesn't in turn depend on GC?

jimktrains2 9y ago
Because that subset of the language will often be different from the actual language.
camus2 9y ago
> What stops you from writing the runtime in the same language, just a subset of it that doesn't in turn depend on GC? At that point you'd better off using C or C++ directly. Go gives you absolutely no advantage, only costly abstractions.
- ben0x539 9y ago
  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.

bjourne 9y ago

Which 8bit microcontrollers do Rust target?

andrewflnr 9y ago
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). High-level blog post: http://dylanmckay.io/blog/rust/avr/llvm/2017/02/09/safer-microcontrollers-almost-here.html http://dylanmckay.io/blog/rust/avr/llvm/2017/02/09/safer-mic... Tracking bug on GitHub: https://github.com/rust-lang/rust/issues/42450 https://github.com/rust-lang/rust/issues/42450

chenglou 9y ago

Fwiw OCaml is a GC language and can run on PIC: http://www.algo-prog.info/ocapic/web/index.php?id=ocapic http://www.algo-prog.info/ocapic/web/index.php?id=ocapic

jimktrains2 9y ago
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.