

Go 1.5 Release Notes - raingrove
http://tip.golang.org/doc/go1.5

======
hencq
The 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.

~~~
chimeracoder
> 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.

~~~
Zariel
The new compiler is now garbage collected, and is generating lots of garbage,
when the old compiler ran without any garbage collection. There is an
interesting thread from the mailing list about this [0]

[0] [https://groups.google.com/d/topic/golang-dev/6obxRcm-
rqc/dis...](https://groups.google.com/d/topic/golang-dev/6obxRcm-
rqc/discussion)

------
ValentineC
Here's the Go 1.5 release schedule:
[https://groups.google.com/forum/#!topic/golang-
nuts/hm9tWv53...](https://groups.google.com/forum/#!topic/golang-
nuts/hm9tWv534bI)

The final version should be released in mid-August.

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

~~~
chimeracoder
> 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!

~~~
ori_b
> 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.

This is why Go was maintaining it's own C compiler -- They had it modified to
work well with Go, as far as I am aware[1].

Removing it means one less compiler to maintain.

[1] From Go 1.4, the source for the Go C compiler:
[https://github.com/golang/go/tree/883bc6ed0ea815293fe6309d66...](https://github.com/golang/go/tree/883bc6ed0ea815293fe6309d66f967ea60630e87/src/cmd/6c)

------
NateDad
_The "stop the world" phase of the collector will almost always be under 10
milliseconds and usually much less._

...and all of a sudden, GC becomes a non-issue for all but the most highly
performing software.

~~~
flohofwoe
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...".

~~~
NateDad
If you'd seen the graphs you'd see that the stop time is related to total
memory used. 10ms only happens with a large number of gigs of memory being
used. For more reasonable amounts (up to a few gigs) the stop times are 1-3ms.

------
arihant
tl;dr - No change in language, one minor consistency oversight fixed. Big
changes on implementation, including compiler being bootstrapped.

~~~
snuxoll
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 -_-

~~~
arihant
Russ Cox said this year that generics aren't left out because of political
reasons or design choice. They are left out because of technical constraints
which are:

\- Generics in current form won't work across the board with all parts of Go.

\- Generics of form that will work for Go across the board are not technically
trivial.

Honestly, I appreciate Go's philosophy of not implementing until fully
understood and accepted. Besides, Go's primary design principle is that of
composability. So you're using reflection in one form or another. Achieving
generic behaviour with interface and reflection is much more consistent than
generics as we know from other languages.

~~~
bsaul
Purely out of curiosity, do you know of any talk that would explain in detail
why things like swift's protocol extension can be implemented in conjunction
with generics, and go interfaces can't ?

From the outside, the two features (swift's protocol with extensions and go
interfaces) seem a bit close, so that made me wonder. I didn't have the time
to think too much in detail about it, so i'm just wondering if anybody already
had.

~~~
pcwalton
You certainly can implement Go-like interfaces alongside generics. There's
nothing inconsistent about them.

~~~
arihant
Yes, but the typical consequences that arise out of that do not fit with
design goals of Go.

Just off the top of my head - boxed types, for example lead to Java-style
inheritance patterns. This sits awfully with composability and readability of
Go code. You read Go code like a tree. You read Java code as multiply linked
list.

------
cpeterso
> In Go 1.5, the order in which goroutines are scheduled has been changed. The
> properties of the scheduler were never defined by the language, but programs
> that depended on the scheduling order may be broken by this change.

Are there any more details about the change to goroutine scheduling? Is this
more than the just change to the GOMAXPROCS' default value?

~~~
masklinn
> 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...](https://github.com/golang/go/commit/202807789946a8f3f415bf00007ee100cf3ec710)

------
ecliptik
Good 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](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.

[https://twitter.com/davecheney/status/567621293109821440](https://twitter.com/davecheney/status/567621293109821440)

~~~
koffiezet
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.

------
EFruit
Back when the dynamic linking design doc was published, it included support
for a 'plugin' build mode, wherein the package was compiled into a .so and a
'plugin' package to load and access said shared objects. Having written a
number of things that would have been greatly simplified by having such a
facility, I'm sad to see it didn't make the cut and has been all but
forgotten. It annoys me greatly to see that C can employ plugins written in
Go, but Go can not.

~~~
NateDad
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.

------
anh79
Mine "go" experience comes with the latest docker 1.7. Ok okay. it comsumes
37% of 512 MB memory. That's fine. I will shutdown all of my apps for you. :P

------
dadrian
They're defaulting away from SSLv3, nice!

------
0xdeadbeefbabe
Anyone know how to cross compile with cgo?

~~~
grey-area
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...](http://dave.cheney.net/2015/03/03/cross-compilation-just-got-a-whole-
lot-better-in-go-1-5)

This one talks about cgo:

[https://medium.com/@rakyll/go-1-5-cross-
compilation-488092ba...](https://medium.com/@rakyll/go-1-5-cross-
compilation-488092ba44ec)

