> 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).
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.