>It's pretty difficult for generics not to adversely affect compile times.
Compared to what? Non having type-specific code?
Because if you manually write (or use code generation madness as some propose) that type specific code you need yourself, then the compiler will take the same time to compile it as if generics were a language feature.
The compiler also has to generate the specialized code. But I suspect that the main factor here is just that the presence of generics in a language encourages the use of generic programming to an extent that wouldn't be practical in a language without generics. Take e.g. the boost geometry library (C++). Theoretically you could write a similarly generic library in Go using code generation, and it would probably take ages to build too. Of course, no-one would actually do this.
I don't know anything about CLU. ML compilers are a mixed bag. OCaml (which is a different dialect, of course), has an acceptably fast compiler, but it's not near-instant like Go. Ada compilers are famous for being slow, at least historically. C# is, again, acceptably quick to compile, but not as quick as Go. I don't know about D. I've heard good things about Delphi's compile times, but no-one uses it now.
In that comparison you forgot the part of turning off optimizations so that the code quality is similar to what Go standard compiler spends time doing.
The compilation speed drop is easily seen when using gccgo instead.
A side note for Delphi, it is still relatively used in European enterprises, with an yearly conference in Germany.
And I could have mentioned other languages like Eiffel, with their mixed JIT for development and AOT via C compilers for final delivery.
Compared to what? Non having type-specific code?
Because if you manually write (or use code generation madness as some propose) that type specific code you need yourself, then the compiler will take the same time to compile it as if generics were a language feature.