
Go 1.7 toolchain improvements - spacey
http://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements
======
tptacek
If you're not a Go programmer, bear this in mind: the Go compiler got
noticeably slower after 1.4, but it is still extraordinarily fast; "run
debounced after every keystroke" fast; "rebuild the world on a whim" fast.

Personally, I think the Go community is a little unhealthily obsessed with
this particular metric.

~~~
khyryk
It just strikes me as amusing, since the tremendous amount of whining about
how much of compilation time (compile-time) generics would add makes the issue
appear important, yet here we have a 2-10x compilation time slowdown, but in
this case it's suddenly totally fine -- the Go community is obsessed about the
wrong things.

~~~
vanderZwan
This is a temporary regression. I guess generics would be a permanent slow-
down, and might not scale nicely for larger projects - although I do now know
enough about the workings of compiler algorithms to judge that.

~~~
pcwalton
I don't think generics would result in a compile time slowdown relative to the
alternatives. If you don't have generics, programmers work around it with code
duplication or they work around it with dynamic typing (interface{}, but also
the runtime support for maps and channels fall into this category). Not
coincidentally, these are the two main ways to implement generics in a
compiler.

------
munificent
There's something vicariously gratifying about posts like this. Optimization
is some of the most fun programming to do: you have a crystal clear objective
goal to go for and once you've got a profiler set up it's just:

1\. Find slow thing.

2\. Make faster.

3\. See benchmark improve.

Some of the most satisfying coding I've done has been optimization.

~~~
steveklabnik
I agree with this, but there's one more aspect: you learn something. Deeply.
"Oh, I didn't realize that would do _that_..."

It's also taught me just how much we can guess incorrectly the first time.
It's a skill you can get better at. "Profile first" is a good heuristic, but
"guess first, profile second, _then_ do the work" means you train yourself
too.

I'm still very much a noob at this.

~~~
munificent
I think _every_ time I've used a profiler, it's taught me that me intuition of
where the bottleneck was was completely wrong. It's a humbling experience, in
a good way.

------
hellcow
I'm glad to see a return to improving compiling speed and binary sizes. Thank
you to the Go team!

------
spriggan3
\- faster compilation times

\- smaller binaries

good job.

~~~
bla2
Faster compared to 1.6, still much slower than 1.4.

~~~
placeybordeaux
C is still the king of speed.

~~~
pjmlp
Not when compared with languages that have modules.

In 2000 I worked on a project where "make clean all" would take 1 hour per
platform/build type.

~~~
placeybordeaux
Oh I meant in execution, not build time.

~~~
pjmlp
Similarly, I remember the days when junior Assembly programmers were able to
outperform C compilers for home computers.

------
lossolo
You can find interesting details to this post in this thread:

[https://groups.google.com/forum/#!topic/golang-
dev/DpMyPbclI...](https://groups.google.com/forum/#!topic/golang-
dev/DpMyPbclI3o)

------
hacker_9
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?

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

~~~
Philipp__
I would like to see that video too...

~~~
charlieegan3
Think it's this
[https://m.youtube.com/watch?v=BBbv1ej0fFo](https://m.youtube.com/watch?v=BBbv1ej0fFo)

------
ruffrey
As someone new to the joys of golang, it is hard to imagine faster compile
time or smaller binaries. It just keeps getting better.

~~~
LVB
_it is hard to imagine ... smaller binaries_

I like Go a lot, and I don't fret about binary size. But let's not be _too_
charitable :). The CLI apps I write usually start trending towards 10MB with a
few package imports. Their equivalents in C are usually less than 100k. One
can imagine getting to better than a 100x difference.

~~~
andreynering
> it is hard to imagine ... smaller binaries

> I like Go a lot, and I don't fret about binary size. But let's not be too
> charitable :). The CLI apps I write usually start trending towards 10MB with
> a few package imports. Their equivalents in C are usually less than 100k.
> One can imagine getting to better than a 100x difference.

Who want smaller binaries can use this compressor tool:
[http://upx.sourceforge.net/](http://upx.sourceforge.net/) It may be a bit
slow but you just need to use it in the distributed version.

~~~
icebraining
That only saves disk space, though, not memory.

------
RichWalton
What happened between Go 1.4.3 and 1.5 which introduced such a slow down in
compile times?

~~~
stefano
They rewrote the compiler from C to Go.

~~~
wund
To be specific I think they used a transpiler, probably Russ Cox's c2go
([https://github.com/rsc/c2go](https://github.com/rsc/c2go)).

~~~
oconnor663
What's the point of doing that? I get that you want a language to bootstrap
itself, but if you skip the experience of actually writing the compiler, and
the code you have to maintain is a weird non-idiomatic machine-generated
thing, what have you gained?

~~~
redtuesday
More developers (who don't know c (good enough), but are proficient in go) who
can contribute to the compiler code long term (and improve the transpiled
compiler). Other reasons would interest me as well.

~~~
chrisseaton
Are there large numbers of people skilled in writing compilers, but don't know
C? I doubt it.

That practical point aside, I do think it's good to lower the barrier of
contributing.

~~~
redtuesday
Yes, I doubt it too. But are they interested in contributing to the go
compiler if they don't already do that? I would guess go users are more
interested in contributing to go. Plus the compiler people who are good at c
and are already contributing can probably get up to speed with go quickly if
they want to and don't know go yet. Or they already know go because they use
it.

------
arktisklada
As an avid go user, I'm excited about these improvements, especially the
garbage colleciton

------
manojlds
Can someone tell me why they went from C to Go despite the huge difference in
compilation time?

~~~
folago
Long story short it's easier to code in Go than C. Here is a more complete
explanation
[https://talks.golang.org/2014/c2go.slide#1](https://talks.golang.org/2014/c2go.slide#1).

------
montyedwards
The only thing preventing me from using Go on Windows is lack of production
quality cgo on Windows x86 and x64.

For example, using external linking should "just work" with recent versions of
sqlite3 but it fails on Windows.

~~~
xrstf
I had no problems building go-sqlite3[1] on Windows 7 x64 using the toolchain
provided by the Win-Builds project[2]. It's using gcc 4.8 and sqlite 3.10, so
maybe that doesn't hit your meaning of "recent versions". It was certainly
recent and easy enough for my needs :)

[1] [https://github.com/mattn/go-sqlite3](https://github.com/mattn/go-sqlite3)

[2] [http://win-builds.org/](http://win-builds.org/)

~~~
montyedwards
I tried TDM-GCC.

In my experience, certain aspects increase risks when using go:

1\. go is buggier for Windows than Linux and FreeBSD, even though they are all
"first class" platforms in go.

2\. cgo is also buggier for Windows than Linux and FreeBSD. cgo is not go, as
Rob Pike said, so this is listed separately.

3\. 386 was buggier than x64, at least in go 1.2 to 1.3 on Windows. I wish I
could ignore 386 and XP but I cannot.

So if a project includes all of the above aspects, well...it wasn't a good
outcome for me, so I ended up sticking with C and C++ on Windows for non-hobby
software.

However, I've been very happy with go 1.4.3 + cgo + x64 on FreeBSD 10 and will
probably update to go 1.6 or 1.7 within a year.

Regarding go on Windows, I'm hoping to see go-sqlite3 issue #272 resolved:
[https://github.com/mattn/go-sqlite3/issues/272](https://github.com/mattn/go-
sqlite3/issues/272)

And go issue #14397 cmd/link, runtime: panic "invalid spdelta" with
-ldflags="-linkmode internal"

And go issue #10776 cmd/link: windows cgo executables missing some DWARF
information

And go issue #12516 runtime: throw in linked c++ library causes app crash even
if caught, on windows platform

And so on...

I really love using go (with cgo) on non-Windows platforms, but I can't see
this combo being useful on Windows for mission critical projects for a while.
There's so much more to go than the language itself and switching gears to use
other languages that don't offer that is painful.

Maybe LXSS.sys will eventually make this irrelevant -- at least for companies
that migrate from older versions to Windows 10 or to a non-Windows OS.

------
verytrivial
(I went to high school with Dave. Hi, Dave! Signed, misc. Banyule Alumnus)

