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.
I'm not sure how repeatedly apologizing for the slower compile time, promising that it's going to get better again in the future, putting an entirely new backend on the compiler, and making it a big focus of every single post about the last three Go versions constitutes being "suddenly totally fine".
To be hypocritical, there must be a difference between words and actions; it looks to me like "we're really concerned about compile times" has been backed up by actions, even if there was a regression. I don't recall them ever promising that there would never be a compile time regression because it was their #1 concern; what I recall them promising as their #1 concern was almost-but-not-quite total backwards compatibility, which they've maintained.
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.
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.
There are still many things to optimize. One of the reasons to rewrite the compiler in Go was to make it easier to profile. The generics issue considers best-case compiler performance.
