Hacker News Reader

Comment by melle | Hacker News Reader

From the changelog: > Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in unidiomatic Go code that performs poorly compared to well-written Go. Analysis tools and refactoring helped to improve the code, but much remains to be done. Further profiling and optimization will continue in Go 1.6 and future releases.

This seems quite a drastic change. I thought compilation speed was one of the pilars of go. In that light, why did they decide to release this anyway?

View on HN

Compilation speed was just a gimmick anyway; the compiler is fast because it doesn't do many expensive optimizations. It was like bragging that using "-O0" makes a compiler so fast. There are languages that require a lot of work just to compile at all, like C++, but for most languages slow compilation is more a measure of how advanced the compiler is.

And it's not just the compiler, the linker didn't even know if a package is used or not, which is why you have to manually remove unused imports (otherwise they would be linked in, bloating the binary).

This is the nature of a priority. They are saying they value compilation speed more than the maintainers of C might, and are willing to sacrifice other things (like runtime speed) in that interest.

This is plain wrong, the main reason the compiler is fast according to the authors[1] is because it handles dependencies more sanely than C/C++.

https://talks.golang.org/2012/splash.article

You're more than welcome to write C in the fashion that the go compiler enforces, and get much faster builds. Their compiler is young and immature relative to things like GCC and stating that it may be missing expensive optimization features is not "plain wrong".

That suggestion is not really practical as you need to make the same requirement from all your third party libraries. While gcc will spend more time optimizing than go, the main reason for the speed difference at the moment IS unnecessary work done by the preprocessor because of the primitive importing.

No, it's not, unless you count time spent compiling inlined functions and templates as "preprocessing time" (which it isn't—it's compilation time). Time the difference between clang++ on -O0 versus -O3 if you don't believe me.

Others already pointed out that paragraph 1 isn't really correct.

I need to point out that your second point about the linker is totally false. The linker knows and does drop unreferenced code. The import strictness is a language requirement and comes from experience with large codebases at Google and elsewhere. Use goimports in your editor's save hook and don't think about it.

It probably takes more effort to write a whiny blog post about the imports behaviour than hooking goimports on save.

2x is still means much faster than C++. Go has an strict release cycle[0] and at some point you have to make the switch if you want a compiler easier to develop. I'm sure it'll get much better soon.

https://github.com/golang/go/wiki/Go-Release-Cycle

Fast builds is definitely a major feature. Go has attracted more Python developers than C++ developers.

http://commandcenter.blogspot.it/2012/06/less-is-exponential...

Go is great as a much faster Python, where speed matters. If Go compiles slow too much, it becomes less attractive.

The compilation time is slower, not the resulting compiled binary.

> On average the programs in the Go 1 benchmark suite run a few percent faster in Go 1.5 than they did in Go 1.4, while as mentioned above the garbage collector's pauses are dramatically shorter, and almost always under 10 milliseconds.

I'm referring to compilation speed. In Python and Ruby, for example, there is no compile stage. This makes them attractive for rapid iteration.

Meh, most people will never notice it, and if for someone is an issue, you can continue to develop using 1.4 locally until 1.6 comes in 6 months.

There is a compilation-to-bytecode stage + lots of file look ups during start up of the Python interpreter and during every module import.

Python caches the bytecode in .pyc files, so the compilation happens only the first time you import a module. In a typical Python start-up only the main source file is byte-compiled.

How often do you compile a code versus run it? Particularly in cases where speed matters?

Why do you think projects like LightTable and Apple's Playgrounds exist?

http://www.chris-granger.com/2012/02/26/connecting-to-your-c...

http://www.objc.io/issues/16-swift/rapid-prototyping-in-swif...

Rapid prototyping doesn't work as well if you need wait for compilation.

JRebel exists for Java to improve redeployment times:

http://zeroturnaround.com/software/jrebel/

You could argue lots of long running server software has been compiled more times through development than it has been started in prod.

They are porting to self-hosted in Go only. And they are willing to trade off compilation speed, temporarily, for getting there at all. Machine translated code will be full of low hanging fruit to get the old speed back.

Reply on news.ycombinator.com