Hacker News Reader

Comment by dom96 | Hacker News Reader

> No, Go isn't a systems programming language because it has a GC.

I don't think a GC excludes a programming language from being considered a "systems programming language".

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

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.

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

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.

We need different terms for "language you can use for high-performance infrastructure" (Go fits here) and "language you could use to implement GC from scratch" (not Go). "Systems language" gets applied to both of these categories.

The former is an application language. It may be a high-performance compiled application language (like Go, Java, etc), but if you can't write a driver / OS in it it's not a systems language.

Go's GC is implemented in Go, but with manual memory management.

Reply on news.ycombinator.com