If not, don't speak so hastily about compiler speed not being important.
Slow compilations means work arounds like batching changes together for tests on commits, which means doing binary searches across commits to find out who broke the tests, or just reverting everyone's commit and telling people to resubmit and hope it goes through next time.
Ever waited a week trying to get a single change committed because you kept getting batched with other people's broken code?
Slow compilation times matter, a lot. C++ is the nightmare case scenario for this, I've seen templates that take 10 minutes to compile, and once a team gets sizable, build queues became a thing, and they slow development to a crawl.
A 100x slower compiler has a huge impact on productivity. Copy and pasting code for those instances where you need to use template/generic programming is a huge win over waiting days for any and all changes to compile.
FWIW typically in these situations local rebuilds are faster, from 10 - 30 minutes in my experience, but I've only had the pleasure of working on code bases of such size twice, so who knows how bad it can get.
Slow (or flaky) build processes create gamblers. You don't want people gambling with prod.
When it's expensive (time or attention) to verify your work, people start lying to themselves. They tell themselves they've done enough, or that red test or wrong data on the screen is "just a glitch", and you know they do this because when they get caught breaking stuff they will tell you the same thing they told themselves.
The progression that works is this:
You make the tool.
You make the tool reliable.
You make the tool straightforward.
You make the tool cheap.
You make the tool mandatory.
People keep skipping step 4 and thinking rhetoric (even verbal abuse) will save them. If you meet idiots all day...
Very true, but the article didn't mention a 100x slower compiler, they mentioned 100% (2x) slower one.
Technically that's a quantitative difference of degree, but it's so big as to be talking about qualitatively different developer experiences.
Even at 2x, you can only 2x compile times so many times until things get unmanageable!
I worked on a c# project in 2011 that had 18 hour builds.
2. Microsoft Office.
Windows Mobile was pre-ssd, but we were surprised when we did get the first generation of SSDs and they weren't an order of magnitude reduction in compile times. (They helped but not as much as we hoped for!)
You deal with boilerplate using either interfaces or code generation. It's not as pleasant as first-class generics, but it's not completely awful either.
Other equally expressive languages have multiple implementations, including REPLs, with Go like compilation speeds.
So Swift and Rust just need equally LLVM fat free implementations for the developer loop, leaving the LLVM backend for the blazing execution release builds.
[1]: http://gistpreview.github.io/?74d799739504232991c49607d5ce74...
For a long time I couldn't stand using it because it's so damn opinionated, but it still hits a sweet spot for me.
I like C a lot because of its simplicity, but hate spending days solving trivial problems.
If you really need C, nothing else will do. But if you're willing to trade some flexibility for convenience, Go lets you make that compromise without dragging along a ton of features that you didn't ask for.
It's a tool, if it works it works.
I write go for my day job; I'm quite aware of their process. They control the language's future and new features pretty much single handedly. Also, I'd be very very surprised to find out that the overwhelming majority of code isn't written by google, do you have a stat on that you can quote?
> it isn't being used to"jerk off into template engines".
I'm saying go doesn't do that. You can't build these crazy compile time abstractions in it like you can other languages, and Google doesn't really need it to because they have enough man power to just brute force it. It doesn't want their workforce build abstractions for abstractions sake, and go doesn't really help you do that.
> or "increase clickthrough rate by 0.1%".
It is very much used to do that, I've been told by product and engineering friends at google.
Still a weird thing to care about. If the compiler were 100x slower, that would still be faster than continually handling boilerplate with human brains.