I, too, would like compile and lint times faster, ideally a lot faster.

That said, the counterpoint is that cross-compilation is not something you can easily bolt on later -- if you aren't doing, and testing it along the way, you will never be able to add it back in. It needs to be there from the beginning and stay a first-class support goal, otherwise mistakes, good intentions and laziness will all yield a product that just can't easily make the leap back to solid cross compilation with no hassle.

Many of the contributions for the ports aren't from the Go team themselves, but from external contributors.

Also, work is in progress to improve build times, although I don't know if that's an active focus, rather than just something that's being fixed as time permits. A few improvements have already gone back to the current development gate for a variety of cases.

I think it's important to remember that development can be done in parallel, just because you see work being done on an area that isn't important to you doesn't mean that there isn't work being done on the area that's important to you as well. Some of these changes take a long time.

Really? I know 1.5 is slower than previous versions, but it's still by far the fastest compiler I've ever worked with.

In the global scheme of things it's still pretty fast, but builds on 1.5 take 2x the time of 1.4, it's pretty bad for existing golang users.

Why is that a problem for you? With golint / gocode I never have any need for extremely fast compilation. What's your setup like that you're rebuilding so often?

Personally, my biggest beef would be that the go developers specifically stood against generics on account of compiler complexity => slow compiling.

It seems they accepted this sacrifice for some other unimportant feature*

*edit: Looks as though the feature they sacrificed performance for was writing Go in Go.

Compilation in Go remains lightning fast, again, faster than any other compiler I use; fast enough that it's sane to run the compiler every time I save a file so my editor can highlight the errors.

I think there are two schools of thought:

1) Perf for a product should be marked against some shipping benchmark and intermediate regressions don't matter as long as we come below the benchmark at ship time.

2) Perf improvements should be "locked in" and not regressed, unless strenuously justified.

I think the parent is of group (2), where it doesn't necessarily matter that it's better than the benchmark of "against other compilers" but only that Go regressed from their earlier perf metrics for what they believe to be inadequate justification.

I think both groups have valid points. I think (2) is especially good at preventing "perf creep" wherein you continually justify small perf regressions for new features, explaining it away that competitors are doing the same. Eventually, you get to the point where everyone's just slow, but they have no impetus to improve because they're still better than the competition.

"Entirely dishonest". "Dishonesty and hypocrisy". In a discussion about compiler performance. Do you understand that framing things like this makes it seem like discussing things with you is intractable?

Absolutely nobody in the universe promised you generics in Go. You may never, ever get them; the longer the language thrives without them, the less urgent they seem.

The way the post you're responding to was phrased is indeed hyperbolic. But I think there is a valid point that compiler performance concerns are a pretty unconvincing reason to not have generics, especially in light of a demonstrated high tolerance for compiler performance regressions.

Why not consult the go faq to find their reasoning for omitting generics?

> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.

The word performance doesn't appear in that paragraph.

Complexity in the type system can easily have a negative effect on compiler performance.

Is it possible that writing the compiler in go makes it easier to add efficient implementations of these missing features?

> It seems they accepted this sacrifice for some other unimportant feature [writing Go in Go]

Writing Go in Go is a huge feature, not an unimportant feature.

Writing the runtime in Go means we write the runtime in a much safer language. We found and fixed lots of bugs just by rewriting the runtime. Everybody, every user benefits from this tremendously.

Writing the runtime in Go means you can have a precise garbage collector. Every user of Go benefits from this tremendously.

Writing the runtime in Go means the runtime implementation becomes in many respects simpler, because there are no longer complex C-Go interactions (the Plan 9-derived C compiler used a slightly different calling convention!). This again reduces bugs and makes debugging easier. Everybody wins.

Writing the runtime in Go means there's one less custom compiler to maintain (no more Plan 9-derived C compiler!). Less maintenance means more time available for more important things. Also this simplifies new ports. Again, everybody wins.

Writing the compiler in Go means you can have a compiler that's not written in a language that sucks for writing compilers. Because writing compilers is now easier and consumes less time, there's more time available for more important things. Everybody wins.

Writing the compiler in Go means you benefit from all the tooling built for Go. This includes source code transformation tools. Automatic refactoring is very easy to do in Go because you have Go parsers in the standard library. This is not merely hypothetical, it's something that's actually used. The end result is that changing the compiler is faster, again allowing more work to be done.

Writing the compiler in Go also means the compiler can eventually become an idiomatic Go program that can be understood by Go programmers instead of being a ken-idiomatic C program that can only be understood by a few people. More people can work on the compiler. More work is being done as we speak, including work that will make generated code much faster. Everybody wins.

Writing the compiler in Go means you don't depend on million of lines of C++ toolchains in order to exist. As a Go compiler writer this has simplified my life a lot. I can compile the Go distribution in under a minute. On my phone. Which is 5 years old. Last time I tried to compile LLVM it died with a compile error after 6 (six!) hours.

Writing the compiler in Go means I can have fun while writing compilers for fun, so you benefit because I write it. Everybody wins.

I've written three compiler targets by now, one in C and two in Go. I don't plan to stop because I like what I am doing, but I'm not sure I would continue to do it if it were still written in C. People benefit from this not only by having more toys to play with, but new ports mean more comprehensive testing and new bugs found. Different platforms exercise different bugs differently, bugs which are present on all platforms.

Also the actual work done on the ports stimulates further refactoring efforts that will make Go even easier to port in the future. Again everybody wins! And it's only because this "unimportant feature" that is not even visible to most users of Go, coupled with the powerful refactoring technology which makes this possible.

Golang has managed to replicate a lot of the virtuous things that happened in the early days of Smalltalk, but in a compiled language. (Has a completely different philosophy about debugging, however.)

Compiling is still sub-2000ms, for me at least. Ridiculously fast compared to other languages. I can see why it would be annoying if compiling was an essential part of your workflow... But I think that would be a mistake.

go test fully recompiles most of the (large) project i'm working on

go test -i

"-i Install packages that are dependencies of the test. Do not run the test."

Does make "go test" complete faster, throws baby out with bathwater though.

ARM is really important. It's probably the fastest growing architecture other than x86 where people use things like this.

I'd also like to see Go on MIPS64, though probably less important than ARM.

Both MIPS64, MIPS, and SPARC64 are in the works (some MIPS bits already merged in).

> Isn't the best course usually to build a solid foundation, then branch out?

Yes, and I think that is what they are doing. First build something stable. Then target a lot of platforms. Then optimize the language itself and also the build times.