Hacker News Reader

Comment by quotemstr | Hacker News Reader

With try, Go might have been a language I'd have enjoyed using. It's a shame. Right now, I see Go as being anti-abstraction and anti-cleverness, and I'd rather not work on codebases in which the language of choice is designed to deter creativity and encourage monotony. Heavy use of Go is a big negative when I evaluate potential projects to work on.

View on HN

Anti-cleverness is what makes Go great. Go code is simple, and it is easy to read/understand. It's a feature of the language

Go code is all about being able to see the trees, forget about the forest. Go programs are rarely easy to read or understand unless they are written by exceptionally talented developers in my experience.

In my experience this is true with any language. I think this is a function of talent and program complexity (the size of the forest), not the language.

I read code for a living and Go was the easiest language to read imo.

I arrived late in a team that worked on a very large Go codebase. To this date, it was the easiest codebase to grok by far.

Agreed. Because golang is "simple", the actual code base becomes a mess, littered with 10 line functions that are basically map/filter/etc. calls, which can be written on a single line in a proper modern language. The majority of golang code bases I've seen are much more difficult to follow compared to if they had been written in something like Java or C#.

Anti-cleverness (in the 'simplicity' sense) is a feature of your coding style, not your language. And I wouldn't even describe Go as being that simple or anti-clever - this proposed feature being a case in point, with its own weirdness tacked on to it that's quite simply unknown in other, even "clever" languages.

Summary of go lang philosophy:

https://www.oglaf.com/delusionist/

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.

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.

New way of solving problems? You're in the wrong business then, programming is not about creativity.

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.

This. I have no idea what GP is referring to. I've seen some really beautiful code written in Golang. Check Let'sEncrypt.

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.

Java style design patterns are often just a crutch for the lack of abstraction in the language.

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.

> 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/

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

> I see Go as being anti-abstraction and anti-cleverness, and I'd rather not work on codebases in which the language of choice is designed to deter creativity and encourage monotony.

I like my tools and projects I work on follow the exact opposite philosophy but I do see your point. It can be a lot of fun when the tools allow you to be creative. It's just that when working on real projects, I'd hate to be the person trying to understand someone's clever solutions. I dread it actually but may be that's just me.

Indeed, I like to think of Go as basically the opposite of Lisp.

Its funny that Go keeps going on how simple it is. Which scheme is much more simple then go will ever be.

Perhaps Scheme is simple, but Go tries to force the user to keep their program simple...

Go's the perfect language for sharecropping developers.

Reply on news.ycombinator.com