Hacker News Reader

Comment by jimktrains2 | Hacker News Reader

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

View on HN

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

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.

Which 8bit microcontrollers do Rust target?

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-mic...

Tracking bug on GitHub: https://github.com/rust-lang/rust/issues/42450

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

> 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.

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.

Because that subset of the language will often be different from the actual language.

Reply on news.ycombinator.com