> If there are complexities that programmers face that can be absorbed by a compiler, it must be

Not sure. If absorbing it would make the compiler much slower, much more complex, or the compiled code less deterministic, or corner cases in the compiler much more numerous, I think it may be reasonable to not go this path.

It looks like the go compiler in itself is a nice piece of engineering, like a F1 race car. And a bunch of guys say they want it with automatic gears. Proposing an automatic version would change too many things in the internals, and the result would be another kind of cars.

> If absorbing it would make the compiler much slower, much more complex, or the compiled code less deterministic, or corner cases in the compiler much more numerous, I think it may be reasonable to not go this path.

Why would that be the case for Generics?

I think nobody says "Go needs Generics, but the implementation needs to be horrible."

In the Go FAQ [1], when they list the purpose of the project, the first answer they give isn't about concurrency (as some might suspect), it's:

  "It is possible to compile a large Go program in a few seconds on a single computer."

They've been consistent about this. It's a major design goal and, for some, compilation speed is worth more than support for Generics.

[1] http://golang.org/doc/faq#What_is_the_purpose_of_the_project

Any language with modules and generics and production quality native code compiler, does enjoy fast compilation speed.

It is a good sell when the audience only knows about C++ compilation issues.

Last time people were ecstatic about go compilation speed, the speeds cited didn't even hold up well against gcc.. The go compiler is not very fast, but as you point out the features of the Go language makes it amenable to fast compilation.

What kills compilation performance for larger C/C++ projects is include hell and managing build dependencies, which as you point out is mitigated in language with modules.

And with luck, even C++ will finally have modules. Still need to wait a few more years, though.

And yet, the dmd compiler for D support templates and is faster than the gc Go compiler.

I'll say it again: Go doesn't have generics because of implementation complexity. The tradeoff was against the additional complexity that our users would have to deal with.

I don't know where people would have gotten that idea from: https://golang.org/doc/faq#generics

right, because a big codebase to deal with the lack of generics doesnt add complexity at all.

you see, the problem with the complexity of a language isnt real. it is perfectly possible to avoid generics in c++ forever. but there will come a day when you think to yourself, was it really worth it to be this lazy? then you take a peek and (assuming you understand generics by then enough to use it a little) suddenly half of what you have writen so far is for the bin.

I was only addressing the comment of the parent that suggested adding parametric polymorphism would kill compiler performance.

DMD isn't faster than the go compiler anymore

You've said this several times. I believe you, but can you please link to your source? There aren't a lot of comparative compile time statistics out there. Last time I checked, dmd was quite fast regardless--maybe no longer faster than the Go compiler, but within the same ballpark.