Yeah it wins over Java 1.5, but it looses against so many 80's and 90's languages, which offer all of that and, wait for it...., generics.

Oh yeah, and generic lists and maps And built-in testing infrastructure, performance testing, code distribution, linting, code formatting, parsing and AST libraries...

And a built in dependency manager, build tool, documentation generator...

But generics crosses the line because compile-time code generation is so much clearer and simpler and doesn't add any overhead to compilation times because code substitution is not compilation.

pre-Java 1.5 already had all of that.

Where was pre-Java 1.5's generic HashMap? Or closures?

> Where was pre-Java 1.5's generic HashMap?

In java.util.Hashtable as implementation of the java.util.Dictionary interface, since version 1.1 back in 1997.

Implemented using s/interface{}/Object/g with ability to use any type as key, as long as, hashCode() and equals () are overriden.

Also allows for fine tuning of the capacity and load factor.

> Or closures?

In anonymous inner classes. A pain to use when compared with real closures, but doable nonetheless.

That is not a generic HashMap. See masklinn's response.

The fact is, the comparison between Go and "pre generics Java" is a bad one. There are many substantial differences, and blessed parameterized types in Go is absolutely one of them.

In the discussion's context, "generic" is about parameterized types (type-safe collections), not about working on any object.

Which Go lacks and the OP was stating it has.

* Go has a generic hashmap, the builtin map type is one of the magical special-status generic collections (with arrays, slices and channels).

* pre-1.5 Java did not have one, its only parametric type was the low-level array

Ah, ok. That is correct.