I don't think I understand where you are coming from. Reading Go code is pretty painful compared to most languages between the specification and the formatter everything looks identical and there is a lack of intentionality. You can't really reason about method signatures or really tell what source will do given the shape.

I've actually found Golang codebases to be the hardest to read, mostly due to the non-locality of effects from channels. It's just to easy to read a line of code and not know where to move next.

I would argue that code with channels are hard to read in any languages, not just Golang.

I read a lot of code. Reading Go is painful because I have to parse whatever open-coded version of standard algorithms or error handling the developer chose to use that day.

This was exactly my experience when I was working in Go. Each line was easy to understand, but reading actual code was painful because I needed to read so much to figure out what was actually being done. I was basically spending 90% of the time mentally simplifying the code into abstractions so that I could understand the business logic. Then once I understood the business logic I had to zoom back in to check that their inlined reimplementation of various basic data manipulation routines were correct.

Yep. Every layer has to deal with every detail of every problem. So now you get to read dozens of in-line, bespoke implementations of what should be a method call.

I used to read code for a living (security consultant) and I'll ask you this question: you're being thrown in a codebase and you need to understand it in a week, what code do you wish the codebase to be. I'll give you the answer: it's going to be the language you work in, and then Golang if it's not the language you work in.

This is actually a pretty interesting question; hard disagree on Go though. I work in security but I don't do much formal code review, instead I care more about trying to figure out how things work as fast as possible. Go is easy to "parse" in that the language isn't too complicated but navigating the architecture of complex projects is annoying because there is just so much boilerplate everywhere that I have to cut through. It's kind of like how I feel with Java, despite it being one of my strongest languages. Otherwise I actually do know a fair number of languages well enough to comfortably navigate around projects that use them; I think C and JavaScript projects are generally not too bad, C++ can be pleasant or painful depending on how things are structured, and Python is also a toss-up. Rust, Swift, Scala, Kotlin are usually pretty good. Of the languages I really don't know I think I would rank Ruby as one of the worst, maybe TypeScript on the better side?

Brainfuck is also super easy to read, and all codebases look the same. That's not a good thing. A language optimized for reading wouldn't clutter most of a screen with "if err != nil". Something like Rust's `?` would be a far better option.

Agree that the limited formatting options is nice, though.

Exactly. Code is read WAY more often than it's written.

Go is verbose, that's true. And if the speed of writing code is the biggest hurdle in your productivity you're either a true 100x coder savant or deluded.

Go is boring, boring is good when you need shit to work every time. And especially when you can't pick the top1% geniuses to work on it and might need to bring some rando up to speed to the project AND language quickly.

Go is verbose. That slows me down when I’m _reading_ code. Especially when it means the chunk of code I’m reading doesn’t fit on my screen.

Or when I have to pick out what the actual logic is amidst a forest of error handling. Or mentally deconstruct some complicated loop to figure out it's just doing a map, filter, reduce.

Java is verbose, C++ is verbose, Golang is not. Golang actually cared about verbosity. For example, uppercase letter means that your function is exposed, no keyword!