[junk_disposal]

>I don't understand people who hate generics. They are just types and they are here to help the developer write compile time type safe code. interface {} everywhere isn't compile time type safe.

You're right, and the FAQ explicitly says that the designers aren't happy with the choice either.

If there would be a one time compile penalty for generics, it may work. The issue is that if large code-bases (Go's reason de'etre) will now take an hour to compile instead of five minutes, it's just dead in the water.

Also, it looks like they want to make Go a language where all code looks the same. So you won't find team A writing C++ like in 1980, team B writing C++ in OO mode, team C writing C++ in FP mode, etc.

It's so fanatical, that the spacing is standardized.

[stymaar]

> The issue is that if large code-bases (Go's reason de'etre) will now take an hour to compile instead of five minutes

This is just FUD. Monomorphization takes a lot of time, but no one prevents the developer to keep the dynamic dispatch by default and just do the type-checking, this is not expensive. And for people who need more performances you add a compiler flag to perform monomorphization.

[mixedCase]

What you propose adds more complexity on top of generics. The Go team specifically does not want performance tweaks under flags as it adds complexity for no good reason.

If generics are to be added, they can't hurt performance and they can't hurt compile times noticeably. The tradeoff needed is too big to be worth it. If this is such a big problem to you, there are many languages out there that embrace the complexity and the tradeoffs. Scala or Kotlin might be good choices.

[stymaar]

> The Go team specifically does not want performance tweaks under flags as it adds complexity for no good reason.

Giving the user the ability to balance his needs for compile-time or his needs for performance is not «complexity for no reason» imho. There is no complexity from the user's perspective, it's just "optimise" vs don't optimise and compile quickly, like what you have with C compilers. It's really different from other kind of performance tweaks, let say the choice between two garbage collectors with different trade-offs. Anyway I'm aware of the dogmatic stance of the Go team on the «simplicity» mantra …

> If generics are to be added, they can't hurt performance and they can't hurt compile times noticeably.

As I said, pure type-check generics with dynamic dispatch under the hood wouldn't hurt compile time and they wouldn't hurt performances because dynamic dispatch is exactly what Go already does with interfaces.

> If this is such a big problem to you, there are many languages out there that embrace the complexity and the tradeoffs. Scala or Kotlin might be good choices.

Not everybody is responsible for the technical environment he is working in. And I'm not sure that telling «if you're unhappy then GTFO» somebody who says he has a problem with the language is a really good approach.