Hacker News Reader

Comment by Animats | Hacker News Reader

Go is an OK language, and that's the point. An average programmer can write web services in Go without too much trouble.

Goroutines mean the programmer doesn't have to struggle to avoid blocking, or decide what should be "sync" and what should be "async".

Garbage collection means the programmer doesn't have to think much about ownership.

The error handling is a bit verbose. If Go had generics from the beginning, it could have benefited from something like Rust's Result type and "?" operator. That's effectively the same thing as Go's usual error handling, but more concise.

View on HN

The criticism that Go is for "average programmers" almost universally comes from people overestimating how good they are.

I've worked directly with hundreds of highly paid programmers over decades. I can count on my fingers the number that would be at all constrained by using Go where it's a suitable choice (an important caveat).

The rest would have their work highly improved by using Go as much as possible, precisely because it's harder to write bad code in Go compared with most languages.

> it's harder to write bad code in Go compared with most languages

I have worked in many, many codebases and I just can’t say I agree. There are some ways in which go programmers don’t write code as badly as they might have in other ecosystems, but there are plenty of other ways in which they’re actively encouraged to by the language.

And it’s not particularly maintainable. Yes, I can always “just read the code” to figure out what something is doing. But I often have to read more than five times the amount of code to understand what’s being accomplished. On top of that, due to the lack of abstraction power, I have to mentally decompile algorithmic implementations into the actual high-level task they’re actually performing. The (minor, but obvious and) classic example is having to mentally parse every single loop to determine if it’s a map, a reduce, filter, or something else.

Well these are just anecdotes but "five times the amount of code" is an outlandish claim. I've done direct ports of code written in more expressive languages (Python, Scala, others) to Go, and also created SDKs in multiple languages at the same time, and I've never seen anything close to 5x.

Go is certainly more verbose than the more expressive languages but the code is also usually much more robust and reliable in my experience, due to strong types, error handling, the well tested standard library.

On your example, the for loop verbosity is a bit annoying and I'm happy that go 1.23 got user defined iterators to help with this https://tip.golang.org/doc/go1.23#iterators

I did not say that golang apps require five times the amount of code as projects in other languages, I said that I need to read five times the amount of code to understand the high-level task that's being performed. And I would say I need to spend an equivalent amount of time processing and understanding the code that was being read. That is a real, serious cost when talking about maintenance.

The loop verbosity thing was just single obvious example and it's good that golang has finally gotten iterators (though their design is… weird IMO). But it's also only one of many, many issues underlying why go code is much more tedious to comprehend than code written in other HLLs.

I agree. I just finished porting a python module to go. Go was certainly more tedious to code and was 1.6x (not 5x) the size. Explicit error handling not only means you have to check e v e r y t h i n g that returns an error code but also you can't embed calls within calls. For example, to convert text to b64 and then to gzip that, in python you can write b = gzip(b64(text)). In go you have to call the b64 routing first and save the result and check the error, then do the same for the gzip call. (insert sweat emogi here).

> and "?" operator.

To be fair, Go almost go the "?" operator like Rust. The proposal was well received. It wasn't the lack of "Result" that held it back, it was that nobody could figure out how to deal with the handling problem. It's not entirely clear what the Rust-equivalent is for all the other moving pieces associated with "?" (e.g. its defined traits). The latest "?" proposal forces a handling body on each use to address that issue. But at that point all you've done is added another way to write "if". Is that a win?

Reply on news.ycombinator.com