What are some examples of unneeded complexity?

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.

On the other hand, Go’s time format and parse logic is the biggest pile of shit I’ve ever seen in an API.

the replacement for SimpleDateFormat/Calendar came with Java 8 (released in 2014)

Sure, but it is an example of the kind of crappy APIs that littered Java for a long time.

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.

Or any of go’s file api’s…

https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

All of it? For a specific example, try doing any functional programming in Java and compare it to pretty much any other language.

Java's not helpful for FP, but that's an odd example to bring up in a discussion about Go, which is also statement-oriented.

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.

Incidentally, golang is much worse for FP.

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.

Inheritance.

Inheritance does have its place. I've seen verbose and error prone workarounds in golang due to its lack of inheritance.

Even the author of Java, James Gosling, disagrees with you.

https://www.infoworld.com/article/2073649/why-extends-is-evi...

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.

That article was from 2003, and is based on hearsay. It would be nice to ask his opinion again.

At the end of the day, golang has classes also whether they care to admit it or not.

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.