Hacker News new | ask | show | jobs
by stymaar 3410 days ago
> 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.
1 comments
mixedCase 3410 days ago
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.

link
stymaar 3410 days ago
> 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.

link