> It's not noise if you can understand every line written though.

If I can understand every line of a 10,000 line program, is it not still noise compared to a 100 line program that accomplishes the same goal?

> If you don't have to think too much about what code does, you can get a better overview of what's going on.

That's the problem with Go. I do have to think about what the code does, because the ability to abstract things to a higher level is virtually nonexistent.

Take the following:

    items
      .select  { |item| whitelist.include?(item) }
      .sort_by { |item| item.price }
      .map     { |item| item.name }

I don't have to think about what this code does at all. It's obvious. And I am extremely confident that there are no bugs. The Golang equivalent?

    var tmp []item
    var res []item

    for _, item := range items {
        for _, entry := range whitelist {
            if item == entry {
                tmp = append(tmp, item)
                break
            }
        }
    }

    sort.Slice(res, func(i, j item) bool {
        return tmp[i].Price < tmp[j].Price
    })

    for _, item := range items {
        res = append(res, item.Name)
    }

Sure I can understand every line of the latter. It's still noise. And it's only comprehensible by sitting down and carefully reading every single line. Are there bugs? I think not, but I'd have to think through it to be sure. Go took what should have been a simple problem and somehow turned it into something that would feel at home if I was writing a device driver.

Case in point, I just reread this and realized there are two bugs.

I’m simply not convinced about that talking point. It’s an extraordinarily strong claim that it’s comprehensible to everyone.

Sure if you have a 100 lines of pure Go, that should be readable. But take a look for instance at the source for go tool cover. How much time do you need to spend to understand it? Then imagine Rob didn’t write it, but a junior. How much more convoluted would it be?

I'm as torn as some of the other commenters here as Go can feel stifling to me frequently, but I have to say I find Go's readability comes with a culture of reading the source, which can be powerful. Often if I'm using a Go tool and I have questions about exactly what it's doing under the hood, unlike other languages where I have to learn the localized style/conventions/patterns (are you using annotations? Dependency Injection? Thread pools or async?), I can just pop open the source and read it. That doesn't necessarily mean I'll _understand_ what I'm reading easily but it does let me pick up subtleties under the hood.

Hashicorp's tools are great examples; before you could find endless posts online about using their tools I'd often dive into portions of Consul or Nomad with questions. Both of these are complicated pieces of software and being able to read the source helped a lot. On the other hand, trying to debug Werkzeug and Flask in Python is a nightmare of objects inheriting weird properties and all sorts of control flow weirdness, despite Flask ostensibly being a lightweight web framework.

You’re conflating ease of understanding/reading Go code with complexity of a hard problem. I can personally read the standard library, or basically any library, and I regularly do to understand how stuff works under the hood. But certain problems are hard and are going to take time to understand the problem and solution versus a basic idea of some things the code is doing. Eg: reading how a RabbitMQ library is using a parameter versus understanding the entire protocol it’s handling. Go is very nice in being able to read other people’s code where other languages it’s extremely hard. (Eg: I’ve tried to read the code for SQL Alchemy in Python and it’s… very hard)

"It's not noise if you can understand every line written though. " It can still just be noise. Have you never seen getters and setters in Java? Error handling in Go is mostly just noise a well. I mean manually wrapping errors so that you can get a stack trace? Our codebase is littered with span calls that in Java could have been relegated to an AOP library.