Go 1.5 Release Notes
tip.golang.org
Go 1.5 Release Notes
1–10 of 66 posts
Re: Go 1.5 Release Notes
#2Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree?
Re: Go 1.5 Release Notes
#3Here's the Go 1.5 release schedule:
https://groups.google.com/forum/#!topic/golang-nuts/hm9tWv53...
The final version should be released in mid-August.
Re: Go 1.5 Release Notes
#4Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree?
I think it is more dogfooding, no? Or proof of concept/completeness?
Re: Go 1.5 Release Notes
#5Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree?
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.
Re: Go 1.5 Release Notes
#6Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree?
> 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!
Re: Go 1.5 Release Notes
#7The release notes mention the new Go compiler is about 2x slower than the old C based one. It also mentions there's ongoing work to improve this. 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?
For my tiny hobby projects, compile times aren't an issue at all so I'm asking purely out of curiosity.
Re: Go 1.5 Release Notes
#8Quite significant that Bell Labs Unix alums don't want to put up with C any more and actively purge it from their tree?
I think it is more dogfooding, no? Or proof of concept/completeness?
I agree. Also another benefit is that people interested in Go and not in C can now contribute to compiler itself.
Re: Go 1.5 Release Notes
#9Good to momentum is still growing with the arm64 port, I remember a year ago it was looking like it may never happen.
https://twitter.com/maver/status/496376555237806080
but in Feb the story changed and with this release it's well on it's way to a full port.
Re: Go 1.5 Release Notes
#10The release notes mention the new Go compiler is about 2x slower than the old C based one. It also mentions there's ongoing work to improve this. 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? For my tiny hobby projects, compile times aren't an issue at all so I'm asking purely out of curios…
> 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.