It reduces cognitive load, dead code, forces handling errors and forces you to be mindful of what you initialize and use.
Don't we use -WError to force warnings as errors in C++? How is this different?
You don't have to use defer(), yet it allows for neat tricks for tying ends in fatal situations easily.
Its implementation of interfaces feels a bit backwards, but it allows for neat implementations of inheritance and polymorphism.
Python uses underscore as visibility convention, how capitalization is different from that?
Plus, it has a very responsive and well working defragmenting GC, which is great for keeping tabs on memory use.
I'm not a big fan of static compilation by default, but it allows compile once run anywhere (in the same arch) and is an acceptable trade-off for most cases. On top of that it has at least two competent compiler implementations.
Go's shallowness is its power, because it forces you to write boring, yet understandable code backed by a GC which reduces possibility of errors and problems a ton.
I can throw stones to any programming language. Java for its factories of factories, Rust for limiting for what I can do with my pointers and memory, C++ for its footguns, Lisp for its parentheses, etc.
Nobody is forcing you to use Go, Rust or anything. Select the tools you like, and works for problems you have. If we have to have an open mind to accept Rust, and oh we're bullied into that open mindedness to accept Rust as our savior, we can be open minded about Go and look from its perspective, too. Same is true for every programming language actually. From D, to Hare, to Rust, to Go, to C++, to Brainfuck and Malbolge.
I can say there's no sane reason for doing that in myriad of programming languages, but these are implemented and in use, so there are sane reasons these things for at least some people.
Fair, I do think that languages are tools and we should select the ones that are appropriate for a task. But that doesn’t make every tool useful, especially that languages do depend on network effects quite a lot, unlike a hammer. There was no need to introduce a language just like many others, and Go - in my opinion - fails to carve out a novel niche of the PL scene, that would have some legitimacy of existing. Rust with all its flaws is novel, there is no other memory safe low-level language (disregarding exotic/research languages). That’s a hugely important niche, so its “hype” is warranted (even though I’m not a rust fan). For Go, even if we limit ourselves to AOT compiled managed languages, there is C#, Java (with Graal), D, Haskell, OCaml, etc.
As for your mentioned advantages:
> reduces cognitive load
In what way? Please don’t come with the usual marketing that “every line is easy to understand blablah”, because otherwise we would be programming in assembly. Too little abstraction is just as bad as too much.
> dead code
Most AOT languages do that
> forces error handling
It’s literally C’s errno forced on you by the compiler. I hope we can agree that C’s solution is very far from what one would mean by good error handling. It hides the actual business logic, while not even forcing you to handle it (a random if block is not error handling in itself), and accustoms people to just skip over these.
> mindful what you initialize and use
That’s only a problem in C and C++. Also, I don’t even agree it does a good job at it, it basically has multiple nulls for example for no sane reason.
> Go - in my opinion - fails to carve out a novel niche of the PL scene, that would have some legitimacy of existing.
People love to bash C++ and try to replace it day and night. Go is not trying to be "the next step" in programming. Its promise is simple. C, reimagined, for relatively simple tasks. Plus it adds some batteries: green threads, a GC, modern utilities like JSON, HTTP, flag support, better portability out of the box, integrated testing, etc.
In short, it's a better C, written in the spirit of UNIX/Plan9. I didn't expect a cutting edge, exciting, "knocks my pants off" language when I started using Go. It's a mundane tool to be honest, and I prefer boring technology for myriad of reasons.
It's designed to be boring, to get the job done. Not to excite people with cutting edge stuff, and this is the novelty of Go. A collection of mundane ideas combined with care, resulting in a superior experience with no surprises (for the most part).
> In what way? Please don’t come with the usual marketing that “every line is easy to understand...
No, not in a line by line basis, but in project scope. See, Go is a simplistic language. You can't do "interesting" things with it much (e.g.: I love auto-tokenization tricks in C++ iostreams, but it needs an innate understanding how "<<" works in C++ universe). This means there's no hidden "magick" under the code to unpack. As a result, the written code is shallow, transparent and boring. When you open a Go project you don't know, reading it is easy. Because there are no tricks. As a consequence, when you don't think of tricks, but of simple utilities and function calls, the state you keep in your mind becomes smaller.
This results in two things. 1) You can see the whole picture with less energy, resulting in better architectural awareness, 2) You can resume a project much faster, because there's less context to load from memory and code structure. I resume my paused Go projects under 10 minutes. Which is fast.
> Most AOT languages do that
Compilers eliminate dead code, correct, but it lives in your codebase nonetheless. "No unused variables and no unused imports" make you remove the dead code from the codebase too, resulting in a leaner codebase with less head scratches. Less complex codebases means less bugs, more understanding, and faster work. See my previous point.
> It’s literally C’s errno forced on you by the compiler. I hope we can agree that C’s solution is very far from what one would mean by good error handling.
Personally I have no qualms with errno based error handling (and no qualms with exception handling (try/catch and friends)), plus Go's errors provide more context, because error is an object carrying much more information w.r.t. an integer. Also, it makes error handling a must, and skipping over error handling voluntary. If you use "_" instead of error and do not handle it, it's on you now. You had the chance and you skipped it. I think it's a pretty neat mechanism: "You knowingly opt out handling a possible error, and it's your responsibility now. Roll with it". Everybody says that "safety must be on by default". It's Go's safety, and it's on by default. Accepting risks is programmer's own choice.
> That’s only a problem in C and C++.
No. I can leave dead assignments in every language I know, and while it might be eliminated by the compiler itself, it's again cognitive load on the codebase maintainer. See my previous points.
> Also, I don’t even agree it does a good job at it, it basically has multiple nulls for example for no sane reason.
Every language has its peculiarities for "no sane reason" for some people. OTOH, some other people think the reasons for these peculiarities are sane and well justified.
Don't we use -WError to force warnings as errors in C++? How is this different?
You don't have to use defer(), yet it allows for neat tricks for tying ends in fatal situations easily.
Its implementation of interfaces feels a bit backwards, but it allows for neat implementations of inheritance and polymorphism.
Python uses underscore as visibility convention, how capitalization is different from that?
Plus, it has a very responsive and well working defragmenting GC, which is great for keeping tabs on memory use.
I'm not a big fan of static compilation by default, but it allows compile once run anywhere (in the same arch) and is an acceptable trade-off for most cases. On top of that it has at least two competent compiler implementations.
Go's shallowness is its power, because it forces you to write boring, yet understandable code backed by a GC which reduces possibility of errors and problems a ton.
I can throw stones to any programming language. Java for its factories of factories, Rust for limiting for what I can do with my pointers and memory, C++ for its footguns, Lisp for its parentheses, etc.
Nobody is forcing you to use Go, Rust or anything. Select the tools you like, and works for problems you have. If we have to have an open mind to accept Rust, and oh we're bullied into that open mindedness to accept Rust as our savior, we can be open minded about Go and look from its perspective, too. Same is true for every programming language actually. From D, to Hare, to Rust, to Go, to C++, to Brainfuck and Malbolge.
I can say there's no sane reason for doing that in myriad of programming languages, but these are implemented and in use, so there are sane reasons these things for at least some people.
Be flexible. There's no need to be that rigid.