3 ms·
It's not yet idiomatic or good Go code now, though, is it? IIRC the initial state (1.5) was mostly machine translated code from C to Go.
by knorker 10y ago
It's not yet idiomatic or good Go code now, though, is it?
IIRC the initial state (1.5) was mostly machine translated code from C to Go.
- _ph_ 10y agoThe main thing is, that they machine translated the Go compiler itself from C to Go, so the compiler had not so great Go code. The rest of the runtime probably was already human-written in Go before that. And of course, anything which has been under development since then is human written, like the new SSA-based compiler.
- EdiX 10y agoThe rest of the runtime probably was already human-written in Go find -name '*.X' | xargs wc -l in src/runtime says Go 1.4: 21701 .c 33348 .go 19160 .s Go 1.7b2: 3340 .c 77597 .go 33827 .s The assembly growth seems to be attributable to the increased number of supported platforms
- 4ad 10y agoYou should exclude runtime/cgo, since it's not relevant.
- giovannibajo1 10y agoThere's also an increased number of optimized code-paths, like for instance some crypto code in the TLS stacks. The natural way to optimize Go code, for instance to benefit from advanced CPU instructions in modern architectures, is to fallback to assembly.
- 4ad 10y agoThe runtime is written by people, not machines. The compilers and low-level toolchain libraries that encode machine instructions have been machine-translated. The runtime is an example of very good low-level Go code that breaks safety rules. However, it is not a good example of user-level Go code. Note that even though the Go code in the runtime heavily uses unsafe, the runtime is much safer and more stable (we find less bugs) then when it was written in C.