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?