Hacker News Reader

Comment by jbarham | Hacker News Reader

> why is the Go runtime and GC not itself written in Go?

In a word: bootstrapping.

It's a FAQ: http://golang.org/doc/faq#What_compiler_technology_is_used_t...

I don't see how to easily implement a garbage collector in a language that doesn't let you precisely control garbage collected allocations (i.e. making all GC allocations immediately apparent and visible, instead of using escape analysis), for the same heap you're allocating into. You'd have to reason very carefully about the colors of your objects in order to ensure correctness in the presence of allocating into the same heap you're in the process of marking or sweeping or copying. (This is not the same problem as incremental collection—with incremental collection you can count on barriers to handle it for you.)

I wouldn't be surprised if it's doable with some really clever tricks, but it doesn't seem worth it in terms of maintainability. Just use C or C++.

Or, one day, Rust :P.

Or does Rust's optional GC get in the way? I'm not really familiar with that part of the language.

Rust is written in Rust.

(The compiler currently makes heavy use of `unsafe`, in my understanding. At least for now.)

Not an expert, but my understanding was that most of those were either from bindings to unsafe functions (e.g. C++ functions from LLVM) or false positives from the compiler dealing with the 'unsafe' keyword in the code its compiling.

It's increasingly possible to write Rust code without needing the runtime at all; this is what's enabling the current effort to rewrite the runtime from C++ to Rust itself. However, there are some restrictions imposed if you choose to shed the runtime: no use of garbage-collected pointers, and concurrency will be either unavailable or somewhat restricted (i.e. mapping tasks to OS threads rather than green threads).

https://github.com/mozilla/rust/issues/3608

Writing the Go runtime in Go would require the similar ability to do without all the services that are currently provided by the runtime. That is, unless you want your runtime to recursively require itself to infinite depth. :) I'm sure it's theoretically possible, but considering that two of the language's largest selling points are concurrency and memory safety via GC, a theoretical runtime-less dialect of Go would be so near to C that it might not really be worth the effort.

Oberon's GC is written in Oberon in some implementations and Assembly in others, but the SYSTEM package is more powerful in low level primitives than what Go offers in its unsafe package.

Edit: Forgot to mention that it does not do escape analysis.

In Go it is straight-forward to call assembly or C code, so it is well possible to implement projects that need low-level functions. In particular it is no magic to manually allocate memory and handle all memory yourself.

Are there actually popular GC implementations that don't use any assembly?

There arent any restricting semantics in Go that makes a pure go implementation of the runtime impossible.

go's void* http://golang.org/pkg/unsafe/#Pointer

go's syscall mmap function. (Pure Go) https://code.google.com/p/go/source/browse/src/pkg/syscall/z...

pure go pkg with more mmap functionality. http://godoc.org/launchpad.net/gommap

Go's runtime mmap function. (C) https://code.google.com/p/go/source/browse/src/pkg/runtime/s...

Go's base memory allocation function. https://code.google.com/p/go/source/browse/src/pkg/runtime/m...

Go functions body may be implemented as asm. The standard math pkg is a great example of this feature. http://golang.org/src/pkg/math/

Considering all of these features there isnt really a whole lot about Go's semantics that prohibit it from being used in many of the low level projects that are typically written in C/C++.

The point isn't that you can't do unsafe pointer fiddling in Go—of course you can. The issue is that you don't have direct control over heap allocation. The language will heap allocate for you in ways that are not obvious.

Reply on news.ycombinator.com