Go 1.5 Release Notes (opens in new tab)

> Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree?

Go is quite literally written by the people who invented C, wrote C, and made it what it is today. (Ken Thompson wrote one of the first commits to the language).

The reason for purging C from the Go toolchain is that it makes it harder for Go developers to contribute. Go developers already all know Go (by definition) - why make them use a language that they may not know as well in order to contribute back to the project?

Furthermore, mixing C code with Go code can cause performance issues if not done right. While you can expect the official project to "do it right", this still raises the bar for people who know Go and want to contribute, but don't know C as well.

And frankly, I don't think it's that significant to say that they don't want to write C anymore. C was a great language for its time, and it still is a great language in many ways. But it's almost half a century old; it would be more surprising if after almost 50 years they couldn't write a language that they prefer even more!

I don't have the link handy right now, but IIRC there was a mention of some system level differences in how Go might like to change things in the toolchain under the language level which could move in a fundamentally different direction from the C toolchain. An example was in the area of how stacks were created and operated.

I think one could foresee making more changes in the future in that area. It's sort of exciting to think that these fairly low level foundational details which much of programming relies on, could be rethought and maybe get us to a different place than we are now.

More I think that most compilers want to be written in the language that they compile. Go has been moving toward this for a while since the compiler rewrite in Go. It's hard to call yourself a C successor when your compiler depends on a C compiler.

I think it is more dogfooding, no? Or proof of concept/completeness?

Bell Labs alums have never had a specific penchant for C, per se, though their languages have mostly had C-like ALGOL syntax.

And still no generics. Honestly, at this point I just wish they'd add a 'void' alias for 'interface {}' so at least non-typesafe code was only as ugly as the equivalent C -_-

They automatically translated C code to Go code. The objective was to produce correct Go code, speed was not an immediate concern - the auto-translated code mostly is very bad Go code, speed wise. Optimizing the Go code base of the compiler is the next step, planned to happen in subsequent releases.

> I wonder if there are any estimates on how close to the original performance they think they can get. Do they expect to reach parity by, say, 1.6 or will it always be slower?

I imagine that's just a side-effect of rewriting the entire compiler; I'd expect the next versions to improve on the speed.

Though in the meantime, if compilation time is an issue, you can always try gccgo. On my larger projects, it's slightly faster than gc 1.5. YMMV, obviously.

10ms is still a gargantuan amount of time for any type of application that must present a smoothly animated UI (not just games), about 60% of the per-frame budget. Every frame where the GC decides to kick in would result in a skipped frame, which is very noticeable. The only acceptable type of garbage collector for this type of application (and I wouldn't call an animated UI application a "most highly performing software") is a garbage collector that allows full control over when and how long it triggers. This sentence from the release notes "The 'stop the world' phase of the collector will almost always be under 10 milliseconds and usually much less." is completely meaningless in this regard, it basically still says "time required for garbage collection can be anything, sometimes less then 10ms, sometimes more, who knows...".

That's highly oversimplified. It traded throughput for pause time.

(Pause time is not the only metric that matters; thinking that it is is a common misconception about GC that bugs me.)

No, there are many more potential issues with GCs beyond this one metric.

In go 1.4, you need to build the go tools for a given target beforehand. In go 1.5, you'll only have to set some environment variables before you call go build, that's it, but unfortunately this doesn't include cgo:

    env GOOS=linux GOARCH=arm GOARM=7 go build hello.go

This link is a good summary of the situation now and in future:

http://dave.cheney.net/2015/03/03/cross-compilation-just-got...

This one talks about cgo:

https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba...

> Are there any more details about the change to goroutine scheduling?

That would defeat the repetition about scheduling order being undefined wouldn't it?

But according to issue 11372 the answer is that up to 1.4 the scheduler would run goroutines in definition order so if you started goroutines 1,2,3,4,5 it tended to run 1,2,3,4,5. In 1.5 it's biased to favour the last-started routine so it'd run 5,1,2,3,4. Again scheduling order is undefined so the order may change again in 1.6, explicitly relying on it would be an idiotic idea.

They have also introduced limited scheduling randomisation in race detection mode[0] which they intend to randomise further in 1.6 to make scheduling-order dependencies easier to suss out and fix.

> Is this more than the just change to the GOMAXPROCS' default value?

The change to GOMAXPROCS wouldn't have changed the order in which the scheduler picks routines, since it could already be set to a non-default value previously.

[0] https://github.com/golang/go/commit/202807789946a8f3f415bf00...

And by the time it's stable, it will be useless for official iOS development, since Apple will require developers to submit apps in LLVM bytecode (they nicknamed it "Bitcode"). For Apple Watch apps, this is already mandatory.

For Apple this makes sense if they want to switch architectures or add additional extensions to their CPU's and not require all developers to re-submit their apps, but it sucks a bit for the darwin/arm64 port of Go. Maybe we'll see an LLVM bytecode target in a few years? Then Go applications could also benefit from LLVM optimizations.

I don't believe it's been forgotten, they just ran out of time. There aren't infinite code monkeys working on this thing. AFAIK, almost all of the dynamic linking stuff is being done by one guy - Michael Hudson (a fellow Canonicaler who we're paying to help out with the Go toolchain).

Projects slip, especially ones like this which are fairly large and complex. I want Go plugins, too... but it takes time, and shared libraries were higher priority. Once the bugs are shaken out of shared libraries, plugins become a pretty logical (and hopefully small) next step.