6 ms·

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

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.

quotemstr 7y ago
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.
- Thaxll 7y ago
  New way of solving problems? You're in the wrong business then, programming is not about creativity.
- inimino 7y ago
  There's plenty of scope for creativity at higher levels of abstraction than the translation of algorithms into programs. Not being creative about error handling (for example) frees some of the creativity budget for things that I personally find much more interesting.
  - baby 7y ago
    This. I have no idea what GP is referring to. I've seen some really beautiful code written in Golang. Check Let'sEncrypt.
unscaled 7y ago
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.
- UK-AL 7y ago
  Java style design patterns are often just a crutch for the lack of abstraction in the language.
  - apta 7y ago
    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.
- apta 7y ago
  > 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+). [1] https://quarkus.io/ https://quarkus.io/
baby 7y ago
Even if you work on small teams, you use dependencies.

quotemstr 7y ago

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.

Thaxll 7y ago
New way of solving problems? You're in the wrong business then, programming is not about creativity.
inimino 7y ago
There's plenty of scope for creativity at higher levels of abstraction than the translation of algorithms into programs. Not being creative about error handling (for example) frees some of the creativity budget for things that I personally find much more interesting.
- baby 7y ago
  This. I have no idea what GP is referring to. I've seen some really beautiful code written in Golang. Check Let'sEncrypt.

unscaled 7y ago

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.

UK-AL 7y ago
Java style design patterns are often just a crutch for the lack of abstraction in the language.
- apta 7y ago
  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.
apta 7y ago
> 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+). [1] https://quarkus.io/ https://quarkus.io/

baby 7y ago

Even if you work on small teams, you use dependencies.