The difference is when a function has more than one line.
In go, you constantly have to `if err != nil { return }` even with named return values. This is the part that breaks up the flow constantly and hurts readability.
Precisely. As soon as you go beyond a ten-line toy program, you'll hit this problem, and in my experience it's almost universally acknowledged to be a problem with Go.
Rust's '?' sugar effectively replaces the whole `if err != nil { ... }`, meaning it wasn't really honest to list Rust as another language that proves that error handling just has to be verbose and repetitive.
See my comment below. I never use this pattern personally, just wanted to point out that it exists. In general I think passing up errors through the call stack without adding context to them or handling them is a strong anti-pattern. I think many people in the Golang community see this similarly. And by passing an error up the stack with "?" you haven't magically "handled" it, so I don't think that's a fair point.
In go, you constantly have to `if err != nil { return }` even with named return values. This is the part that breaks up the flow constantly and hurts readability.
In Rust, the ? macro also handles this.