- Guy Steele, Java spec co-author

Custom collections in a statically-typed language without macros or generics or templates is masochism. I was very disappointed back in 2005 that it took competition from Microsoft with .NET 2.0 to force the Java leadership's hand to finally provide that missing feature.

Why even bother with static typing if coders are constantly having to type-cast and null-check everything?

Go maps are an explicit exception in the type system. They have their own type rule. And in the syntax. They have multiple map-specific syntax rules (and not just literals). And in the semantics (e.g. using range on them).

Go doesn't have maps, as such. Go has an inbuilt language feature of one particular type of map, that I assume is thought to be good enough for everybody.

But if you prefer, advance a few years up to 2004 (1.5), still 5 years before Go was created.

Also HashMap is just one implementation among all of those that are available in the standard library for the Map interface, each one tailored for a specific use case, with regard to performance and memory constraints.

In Go you cannot change the behaviour of that built in hash map.

Java is a great and extremely well designed language. All you mentioned are nothing but natural expansion of the language's use cases.

I'm mostly seeing Java treated like a legacy or a conservative choice - not something I would describe as great. JVM has a lot of quality engineering but there are better languages to leverage that ecosystem.

I love lines that say so much with so little. Well said.

Java was the right language at the right time. That's why it was so successful.

any moderately-usable language with a free, cross-platform compiler and a full batteries-included library for everything and support for every major platform and a major vendor pushing it and the kind of global marketing PR (The Official Programming Language of Canada!) would have seen the same success as Java at the time.

The quality of the language design itself was "passable" at best, but that's all it needed to be with the forces it had pushing it and the market conditions at the time.

It's hard to look at a historical success, and determine which attributes caused that success. I agree that the non-product attributes (tooling, docs, libraries, corporate backing etc) were important. Elsewhere you describe it as "moderately-usable", and I think that implies the key: to compare it with the alternatives, such as C++ and COBOL. That's how market success comes about.

It's similar with google: was it "the algorithm"? Or was it honest results, uncluttered, fast?

Java doesn't represent anywhere near the full depth of what Gosling actually knows about programming languages. You remark about "static typing without generics or macros to make reusable collection". Yet, Gosling made a structural macro system for the C language in 1989. The ideas in that could easily have been further developed in Java.

From Mock Lisp to Java: the really unfortunate thing about Gosling is the cynicism in his designs.

To be blunt: this is not hindsight. This is me remembering working with Java in the early 2000s. These were things that jumped out at me as an undergrad student as obvious pain-points in a new language I was learning that were not present in other languages I had used.