I think that's quite on purpose - a lot of folks seem to look down on 'clever' code. I think at its extreme we can almost all agree that hyper-clever code is a bad thing. I think we just differ on where that threshold starts for every day code.
Apparently (early) Java was designed in much the same way, just to a lesser degree.
I'm not a fan of languages specifically designed to limit me from expressing myself. Then again, I work on small/disciplined teams, where this tends to work out pretty well.
Java-the-language was designed to be anti-clever, but a decade later, most code written in it ended up being the epitome of hyper-cleverness.
Lack of abstractions (a.k.a "cleverness") on the language level, pushed developers to abstraction on the code level, often based on reflection and supported by XML files and (later) annotations.
In retrospect, by avoiding cleverness in Java, we ended up with multiple incompatible framework dialects which implement their own cleverness.
Go avoided this fate so far by having weaker support for reflection, and since the collective developer memory of Java framework excesses is all too fresh. This makes Go code more readable than Java on average, but I don't think it's any more readable than idiomatic code in a high-abstraction language like Rust, Kotlin or Swift - once you learn and internalize how these languages work.
> but a decade later, most code written in it ended up being the epitome of hyper-cleverness
Citation needed.
> we ended up with multiple incompatible framework dialects which implement their own cleverness.
The trend for a while now is using libraries on a per-need basis. E.g. [1]. This also doesn't sit with reality based on the different JEPs available, and standardizations like JPA.
> but I don't think it's any more readable than idiomatic code in a high-abstraction language like Rust, Kotlin or Swift
I haven't used Swift of Rust in a significant manner, but golang is way less readable than Kotlin, and modern Java (8+).
golang has its "patterns" as well, which are quite badly designed.
Java's modeling and abstraction capabilities way supersede what golang has to offer. This is much better now especially after Java 8 and continues to evolve.
I agree. Go does remind me a lot of early Java. And for some domains, you do want generic easy-to-produce uncreative code of the sort Go encourages.
It's just that I personally do not want to work on a project for which the technical need to repeated uncreative execution. I want to explore new ways of solving problems, and Go is not the language for that. That's why use of Go is a reliable signal.
Apparently (early) Java was designed in much the same way, just to a lesser degree.
I'm not a fan of languages specifically designed to limit me from expressing myself. Then again, I work on small/disciplined teams, where this tends to work out pretty well.