[lederhosen]

You can not have a custom collection class containing objects _only_ of a certain type. For example ConcurrentHashTable<Int, String>. That is something that is used every single day. It is used so frequently that Go has generic slice and map built into the language. That is, they created a language with lots of special datatypes that can not be created in normal Go because of its lack of generics instead of creating generics.

It is a bit like asking a Java-programmer to use Java 1.4.

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.

[dilatedmind]

Not without either implementing it yourself or wrapping interface methods.

Go generate is like a manual step for having generics, I imagine one day soon its functionality or something similar will be part of go build.

In response to your particular example, a map plus a mutex seems sufficient.

I dig that it's a few extra lines of code, but I guess I'm looking for a really mean example.

[coldtea]

>I dig that it's a few extra lines of code, but I guess I'm looking for a really mean example.

Well, if you don't care about repeating yourself, mistakes by omission, needless boilerplate, and/or loss of type safety, then, sure, everything is possible in "a few extra lines of code" in a turing complete language...

[lederhosen]

I can not create a really mean example because Go is Turing complete. That means that everything can (with a few extra lines) be expressed in Go.

The problem with your mutex solution is at least two:

1) it is more complex

* more lines to type and read and check and thus harder to understand

* you can forget the mutex

* if you have data structures of hastables, you will have to pass mutexes around or store them together with the tables.

2) it is not nearly as performent as a lock free hash table

(edit indentation)

[pjmlp]

Back when Borland C++ 2.0 came out for MS-DOS, templates were still being designed.

So the first version of BIDS, Borland's C++ data structures library, used pre-processor tricks where one defined the types before including the respective data structure.

So go generate as workaround feels quite old.

[taeric]

Oddly, I have pushed back on many devs introducing generic interfaces. For library writers, they can be nice. For everyone else, they typically just get you in trouble.

So, I don't want to remove them from the language. However, I do question a large percentage is their use in everyday programming.

[lederhosen]

Generics are useful all the time. That is why Go has generic Maps and slices. The question is why I am not allowed to use other generic collections.

[taeric]

No, generic collections are pretty much useful all of the time. Other generic things are useful when done well.

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