> Is there really anything else in Go than "pretty good standard library".
An easy to understand language spec, a compiler that can spit executables that don't depend on glibc, no dependencies on Python 2, and most (if not all) packages under /x/ are BSD licensed.
> Error handling is from the stone age
I actually prefer this approach to explicit error handling, as opposed to the trendy "uncontrolled non-local gotos" approach (a.k.a. "exceptions". I'm borrowing that term from someone else).
The only sane-ish approach to exceptions I'm aware of is that of Java, where you explicitly have to tell which exceptions can happen, and force you to either handle them right there, or modify your function signature accordingly.
Still, with a big `try/catch`, if two calls throw the same exception, both exceptions would go to the exact same `catch` block.
Yeah, thanks, but I appreciate how Go makes ignoring errors very eye-catching. Makes code review easier.
> no support for generics
Devs are actually very open to generics. The thing is, nobody has, as of yet, proposed any implementation that would play nice with the rest of the language.
> no support for functional programming
I don't see the problem. It's not like every new programming language should support every possible feature known to humanity. They would end up like C++, where you don't know if the next version will add the Unreal Engine to the stdlib.
If anything what we need is more minimalist programming languages, not the next bloat of the century.
> no real enum but instead "a hack" you have build by yourself
I can see the point here.
> dependency management without versions
This is actually one of the things I like the most about Go. "Fix your thing to work with the latest version, or bundle your working version", sounds very reasonable to me.
No concept of versions, no centralized source for anything. Just repositories and an ad-hoc way to setup your "registry" just by including an HTML tag in a web server you own.
The only assumptions made about "packaging" is that (1) they're somewhere on internet, and (2) you have the command necessary to fetch them.
If anything, what I don't like about `go get` is that adding a new "handler" requires recompiling the `go` executable.
> Also the hyped features such as channels are nice, but nothing a simple Rx-library couldn't do.
Sure. Go brings nothing new to the table.
> Due to the language limitations it's also nearly impossible to write elegant code with Go.
Most Go code looks elegant to me. Same formatting everywhere (except when someone does not use `gofmt`).
It also means that whenever I see `a + 1`, and the code compiles fine, I know it's a numeric addition, and not an HTTP request, for example.
Go is like a language with some linting in the spec. Compiler error for unused variables? Yes thanks!
Makes reviewing code easier.
> If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same
Looks like a plus to me.
> Tons of "if err != nil"
I don't know, I always considered a good practice to handle errors as soon and as explicitly as possible.
> and for loops.
WHAT!? No more `for (;;) {}` vs `while (1) {}` discussions!!!11!1!!ONEONE.
Making people think twice before introducing the Go equivalent of `Array.prototype.forEach` vs `_.each` vs `$.each`, looks like a plus to me as well.
Working as close as possible to the primitives unless strictly necessary.