Having used both languages for many years, it was unexpectedly irritating to pick up Java again after doing golang for a few years. So much unneeded complexity to do simple things.
While not strictly the language itself, I find the Java standard library API to be unnecessarily verbose, with often obtuse defaults.
Go’s library is sometimes overly terse, but after having experienced both in production, I much prefer Go’s style.
An example is one of the date parsing functions (I can’t remember details now) which will happily accept an invalid date string (eg 2021-02-35) and silently convert it to a valid date (2021-03-07) despite declaring a parsing Exception.
You see, you only get the exception if you call setLenient(false) or if the date string can’t be coerced. For the life of me, I cannot think of a use case for this behaviour, and it certainly violates the principle of least surprise.
I think Java has one of the best standard libraries out of any language I used. Sure, it has its warts (but the Date class should really not be used anymore over its more modern replacements, which are again, really sane), but it doesn’t make you reach for third party dependencies at every turn, neither for lack of feature nor lack of performance. Sure, you can use hand-tuned collection libs, but it is very seldom needed.
Crappy apis is not beholden to java. Have you looked at go's timer API? Try to re-use one without inadvertently causing a data race, or get wrong behaviour.
I am far from a Java guy, but that seems like a poor example. Functional programming is not in the wheelhouse of Java. In the same way, it would be unfair to criticize Haskell for its object-oriented style.
It really is not that bad, and it is at least possible, both to incorporate it partly (stream api, immutable objects, especially with records) or go full-on with vavr.
As to workarounds for inheritance in Go, that sounds like trying to write in another language but in Go, which is of course not advisable in any language.
> Even the author of Java, James Gosling, disagrees with you.
From the article:
> Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.
Key words: preferable, and whenever possible. It's sometimes preferable to have inheritance and not possible to leave it out without unneeded extra complexity.
Furthermore, nowadays interfaces in Java (as well as Kotlin, Scala, C# - all of which are much more expressive and have superior modeling capability than golang) can have default implementations, which increases their application even more and reduces the need for explicit inheritance. Not so in golang since interfaces cannot have default implementations there.
> As to workarounds for inheritance in Go, that sounds like trying to write in another language but in Go, which is of course not advisable in any language.
Not quite, it's just where having inheritance would have simplified the design, and improved readability.
He quite clearly states in the article he would ‘leave out classes’ (i.e. implementation inheritance). You didn’t quote the clearest statement in the article, just preceding your excerpt!?
Again on interfaces, sometimes less is more. Many people prefer the inverted interfaces of go, declared at point of use. It’s fine to prefer the opposite, but these are deliberate choices, not mistakes or failures.
Re inheritance simplifying a design, it does the opposite in my experience, unless by simplify you mean hide program flow and state.
The implication of "whenever possible" is that an OO language should strive to maximize this metric - for example, by making composition easier (e.g. providing syntactic sugar for "implement this interface by delegating all methods to this object").
But yes, Go is definitely worse in that respect, not better.
