[lederhosen]

If you value compile times (and you actually think generics make a difference, I do not) you would not make slices and hash tables generic like in Go, would you?

If you wanted a simpler language, you would not make slices and hash tables generic, would you?

If you wanted lower learning curve, you would not make special case generics would you?

If you wanted to wait, to get the perfect generic solution because a sub-optimal one is not good enough, you would not create a sub-optimal non-perfect temporal solution with special-cased generics for certain data types would you?

If you argue that I am loyal and not honest, and therefore like generics because it is used in my favorite language, I think you are wrong.

The languages I use most of the time have a huge design flaw. It is called null. But when they created Go they chose to (except in special cases) get rid of (useful) generics instead of the disaster that is null.

The problem is that Go has not learnt from other languages. It is too imperative, not expressive enough, lacking in static typing and horrible at fault handling.

[foldr]

>(and you actually think generics make a difference, I do not)

It's pretty difficult for generics not to adversely affect compile times. This is especially so if you actually emit specialized code for each type.

[coldtea]

>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.

[foldr]

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.

[pjmlp]

I bet CLU generics as designed in 1971 hardware would compile quite fast on modern hardware.

[foldr]

Maybe. I don't know. It is pretty difficult to find examples of languages with generics that have compile times comparable to those of Go.

[pjmlp]

Easy, CLU (1971), ML (1973), Ada (1983), .NET (2003), Delphi (2007), D (2007).

Not every implementation needs to be turing complete C++ style.

[foldr]

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.

[pjmlp]

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.