Yes, that is a very nasty bug indeed. I think I'll be sticking with 1.4.2 for quite some time..
Does anyone else feel like 1.5 was released prematurely before it was honestly ready to go out the door? At this point Go is more than 5 years old; these kinds of amateur issues seem unacceptable.
Can anyone comment on what it's like when new versions of Java have been released throughout the past 20 years? I am curious if regressions and stability issues are common in that ecosystem.
My experience with Scala has been that things are quite bulletproof by the time they actually get released for wide-consumption.
> Does anyone else feel like 1.5 was released prematurely before it was honestly ready to go out the door? At this point Go is more than 5 years old; these kinds of amateur issues seem unacceptable.
Honestly, no. All software has bugs. The Go codebase is very solid, in general. It's hard to get away with as much change as we've had between 1.4 and 1.5 without a few issues slipping through.
At Google we've been running 1.5 in production for a while and didn't catch this issue. As have a lot of our other users. But inevitably when you release the stable version more bugs are uncovered; this is just life.
Conservative users should certainly wait a few days (or weeks) after a major new version before upgrading. Historically we have released version 1.N.1 within a couple of weeks of each major release. If I were you I'd just wait for 1.5.1.
edit: I think "very nasty" is overstating things. The likelihood of real code triggering this bug is extremely low.
It's certainly surprising, particularly since Go has its own extensive test suites and quite a few people have used the prereleases (including being deployed within Google and running all those tests as well).
It suggests the error is somehow not that commonly triggered in a visible way, or lots of tests would have broken. Or alternately it was a last-minute change.
Looks like a register allocation bug, which is the kind of thing that can only trigger in specific circumstances.
It looks like the Go compilers are especially vulnerable to this because individual AST nodes have to allocate registers, which would not be a problem if they used a more traditional IR.
Agreed, considering this was a major rewrite of the core compiler in converting for C to Go, I don't understand why they rushed from release candidate (August 6) to release (August 20) in 2 weeks. I'm all for schedules, but in this case more regressions and a longer release candidate timeline would have been warranted.
This also stresses the importance of random codegen testing and fuzzing, where test cases get run on v1.4 and v1.5 simultaneously and compared against each other. A simple fuzzer should have caught this.
The good news is this bug was caught on the same day as the release.
It wasn't exactly a rewrite... the C code got passed through a tool that converted it from C to Go in a way that tried not to change anything. Now they have a bunch of non-idiomatic Go code that should do what the C code was doing before more or less. Judging from my use of Go 1.5 so far, it did a pretty good job but made the compiler noticably slower.
>Does anyone else feel like 1.5 was released prematurely before it was honestly ready to go out the door?
Nope. I would consider it the same as moving from 1.7 -> 1.8 and having things break/bugs occur. How many people in the Java ecosystem are still on 1.6 for whatever reason? It may have been fixed before release if more people tested the release candidate (but that never happens), and unfortunately for software "x.0" ends up being the "public beta".
I remember in 1.3.0 where I reported a bug (that also had to do with string/byte slice weirdness), that was fixed pretty quickly and landed in 1.3.1 (https://github.com/golang/go/issues/8325).
