Dragged them out to an ocean halfway between two islands, imho.
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?
I wonder if it's okay to state it like that, actually. Java's Hashmaps are typed, in the sense that it's implemented using the type system.
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.
Absolutely. The JVM is great, and JVM languages like Kotlin and Clojure. Even modern Java is a good language. I'm not arguing that Java hasn't come into its own as a good language. My point is that the Java I cut my teeth on? "Java 2"? That was bad.
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?