It's a shame too. The language is actually quite nice. They made a lot of decisions that simplify and improve code quality, large code bases, etc.
However a few decisions are huge signals that they didn't really think through them. Error handling and the now-solved package management are two big ones.
> They made a lot of decisions that simplify and improve code quality, large code bases, etc.
I keep seeing those claims (e.g. "programming in the large"), but in my experience, practically all the decisions in the language make it more awkward and difficult, even unnecessarily so, to deal with large code bases.
golang's interfaces for instance, are optimized for a small use case, at the expense of them being useless for actually useful things, like tagging and fast code search. The way "methods" are assigned to structs is overly verbose, and makes it easy to have to jump around even several files to figure out all functions that are tied to a struct. The list is too large to list here.
So, in the large codebases I've been a part of I think Go makes it easier.. BUT, it's an asterisk "easier*". The asterisk being I think it's easier to reason about Go projects, large and small, in a "local sense" only. That is to say, I think you can wander around Go code with less context on the whole project and have a better idea on what that tiny piece of code is doing.
Compared to my Rust code bases, I feel like you need a larger picture of the project to understand what smaller code pieces do.
Is that a good thing though? Not sure, honestly. Should I really feel I understand what a function does, without understanding the functions role on the project itself? How can I truly understand a function without understanding its role?
Go feels like it's easier to understand the implementation, but not the context/purpose. Arguably, this may not be good.
> That is to say, I think you can wander around Go code with less context on the whole project and have a better idea on what that tiny piece of code is doing.
Again, what specifically about golang that makes it that way, other than errors vs. exceptions (keeping in mind that any line in golang can panic)? And what's preventing you from writing similar code in another language? I used Scala before and we had Option and Result types, and treated exceptions as panics. The same applies to Rust.
I found that because of golang's verbosity, it actually made it harder to understand what the entire project was doing. e.g. code bases I worked with were littered with one off functions that amounted to what basically was a map or map+filter, where this would have been a one liner in any modern language, including Java, C#, Kotlin, etc.
Basically, I'm agreeing with the rest of your comment. I find that a "denser" language (to a certain extent) allows you to understand the overall project quicker. There's probably a sweet spot somewhere, and I feel that languages like Java and C# are quite close to it. Keeping in mind that you want a high level overview of a project when you start off anyway, there's no magic solution that will give you that.
It's just that I keep seeing the same claims repeated so many times, and it really seems that they're just being repeated without any basis at all, and repeated just because what the golang author's claimed. So far, almost everything I've seen has been hype.
I used golang at an employer and you're right, it's a huge mess (and error handling is just one part of it).