[nordsieck]

> You can not have a custom collection class containing objects _only_ of a certain type. For example ConcurrentHashTable<Int, String>.

I'll start by saying - I largely agree with you. Libraries, particularly of data structures, are the biggest weakness of Go as a language.

However, this bit is not really fair:

> When you ask a Java programmer, or C# programmer or Haskell programmer or Swift programmer or... what they would change in the language you do not get the answer: remove generics.

Much like values, language features need to be compared to each other, not evaluated in isolation.

Everyone likes loyalty, but some people value it over honesty and some value the reverse.

Everyone likes generics, but some people value faster compile times, a more simple language implementation and a lower learning curve more. Some people value it less.

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