[smeg]

Well given that the current runtime (written in C) doesn't have a runtime, I would assume there wouldn't be one, as Go compiles down to native code just like C does, using the same toolchain (6c/g -> 6a -> 6l).

My current guesses are: 1) Performance 2) The need to call assembly code easily

[msbarnett]

C is capable of running without a runtime, but Go isn't. This has nothing to do with compiling down to native code and everything to do with the language semantics.

[smeg]

Right, so native code generated by Go probably needs some kind of runtime initialization before it can even start executing.

[msbarnett]

Among other things which aren't expressible in Go, that's part of it. You could do those bits in Assembler and the rest in Go if you really wanted to stay out of C, but the net effect is just that the language runtime becomes harder to port to new platforms.

[4ad]

Please note that you can call assembly code from Go easily.

The runtime needs to break the abstractions Go provide, it needs to break Go's memory model, it needs to be aware of the garbage collector, it needs to be aware of stacks, stack growths and switch them, and it needs to do other things: http://research.swtch.com/goabstract.

C was chosen as the pragmatical choice, they could have done it all in assembly (various bits are written in assembly), but C is a portable assembler.