I'm confused how Go can be paraded as a low level systems language, which improves performance via concurrency, and yet the graph says it's compiler is still over twice as slow as when it was written in C?
It's not a low-level systems language in traditional view of what "system" is. For Google, "system" is a cloud, not the hardware, so take it from this perspective.
By the way, here is a nice video of Q&A session with Alexandresku, Matsakis, Stroustrup and Pike (D, Rust, C++ and Go creators), where they also explain what does 'systems language' mean.
It's worth noting that in Rust terms, this video is a bit old. I haven't watched it in a while, but some stuff might be inaccurate now. For example, Rust still had a runtime and green threads then.
It was auto-translated from C to Go. This means, they replaced well-written C code with badly (unoptimized, nonidiomatic) Go code. The reason was, to guarantee that the initial Go based version was identical to the proven C version.
With the releases subsequent to 1.5 the cleanup and enhancement process of the Go version started and now it shows nice results.
I think its one really great feature of Go, that the whole build/runtime infrastructure is written in Go itself. So, everyone who is fluent in Go can easily read and possible enhance the infrastructure.
I don't think the Golang people are parading it as a "systems language". Part of the goal was to make something fast that's both safer and easier than C. I think they succeeded with that. But I don't think anyone expects a language with enforced safety and built-in garbage collection to be faster than C. That just isn't going to be possible.
Its an irritating dual meaning of "system's language". For Rust, D, C++ and the rest of the world, "systems" implies drivers, OS and embedded systems where low level memory management is key. For the go developers, a system is a web-service so its actually competing with GC languages like node.js and Ruby rather than C.
I don't know anyone who has written more than a toy OS in Go, but it does not seem a fundamentally impossible task. Getting started is harder, because the earliest parts of the kernel would be modifications to the runtime package. Once you get that out of the way, writing drivers could be quite fun.
But to the broader topic, I don't have a good definition of "systems language" so I'm not going to claim Go is one.
Hi crawshaw, thanks for your work on Go in general and smaller binary sizes in particular. Could you explain why cmd/go generated by Go tip remains larger than the one generated by Go 1.4.3?
My guess is that Dave Cheney is measuring the cmd/go that comes with the release, meaning it's a different program each time it is measured. Someone probably snuck some new features into it between releases. :-) Like all the -buildmode support for shared libraries, building .so files to load from C programs, etc.
I have been using it in my binary size measurements as I work on http://golang.org/issue/6853, and it has shrunk reasonably well since the 1.6 release. More to come!
An OS often has to generate nearly every opcode on the target machine (many are there just for this purpose). Can Go generate arbitrary ASM instructions?
An OS has to deal with often strange calling conventions (interrupt routines, OS entry point traps, multiple language support). Can Go express the calling stack in any way?
Drivers are often interested in controlling timing and latency down to the instruction. Can generated Go code be examined by the developer for instruction counts?
A good kernel language is pretty low-level. Used to write them all in assembler.
I have used it in sticky situations, like the trampoline for a signal handler, and writing functions that have to conform to a C ABI because they are called by the OS. (In particular, a loader .init function.)
To minimize how much assembly a theoretical OS author has to write, there are a couple of extra tricks in the runtime package they could borrow, like //go:noescape annotations. You have to be careful when writing code like that, but it does the job.
Before the Go runtime was rewritten in Go, I worried that for a task like writing a kernel there would be a lot of assembly. But I have been pleasantly surprised by how little is needed in the runtime, and that gives me some hope for a project like that.
Of course this is speculation on my part, I could be wrong.
But the D standard library also relies largely on a garbage collector, so it's questionable that it differs much from Go in that respect.
As most things, it's a spectrum and not binary. Userland is also part of an operating system and could be written in Go without much trouble. One could also argue that things like Docker are also systems programming.
Go is less 'systems programming' than C, C++, or Rust, because it has a garbage collector. Go is more 'systems programming' than Java, C#, node.js or Ruby, because it compiles to native binaries, provides value types (C# does too), integrates more tightly in standard UNIX APIs, etc.
BTW, as D can call C functions.
Thus, in theory, you could choose to use only the C standard library, and use D as a "C with a better syntax".
This way, no garbage collector nor any bloat gets linked into your program ... but you still benefit from RAII, templates, array slices, and simplified declaration syntax.
Even though I am not a big fan of some of Go's design decisions, this is one area where I do say that Go is a real systems programming language specially since 1.6, regardless of what C guys say.
You have OSes written in Lisp, Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Sing#, System C#,...
All systems programming languages which do have a GC for heap management.
Given that the Go compiler and runtime are written in Go, with the necessary Assembly glue code, I would say Go is no less systems programming language than those referred above.
Even ANSI C, cannot be fully implemented without Assembly or compiler specific extensions for hardware integration.
But of course the naysayers will only change their discourse the day someone decides to invest their time and produce a bare metal runtime for Go, following the approach of one of those OSes that I mentioned.
If the system includes the task of its own maintenance (and therefore the developers who work on it), go is faster than C because of maintenance and correctness advantages. (that definition of system is more like 'systems biology' than 'close to the iron software that calls OS APIs').
If golang stays popular the compiler will keep getting faster. Especially because now that it's self-hosting, future improvements will improve compile & runtime perf.
