Go is what happens when you give people who have no idea about languages Google-level resources.
This is the lamest sort of language spat. It's football hooliganism except not about football. We don't want it here.
True. But it's a complex topic so in reality these are highly correlated.
> This is the lamest sort of language spat. It's football hooliganism except not about football.
Admittedly my top level comment had little substance to back it up. But as others have pointed out in the thread Go is objectively several decades behind the times. If that doesn't count as not knowing about languages then I don't know what does.
I am perpetually baffled by this particular defence of Go. Go has a number of real strengths, but it also has several howling, inexcusable, flaws. How can you possibly say that that this is the work of people who are expert in language design?
Not a language.
> Plan 9
Not a language.
> B (the predecessor of C)
A version of BCPL, stripped down to fit on the hardware they had. Considerably less sophisticated than Algol, which had been designed years before.
> Inferno (a successor of Plan 9)
Not a language.
> UTF-8
Not a language.
> They definitely are experts in language design.
What?
It's hard to admit, but all of the languages we have are of amateurish quality.
Does the "wrong" way always tragically win in the marketplace of ideas? Maybe our (sub)culture has a screwed up idea of what "right" is?
(Such things were asked in the Smalltalk community for years.)
There was a period of time when this was true, which helped to kill Smalltalk mindshare. Then, there was a period of time when there were many economically priced Smalltalk environments, and a even a good FOSS one. Now, we have a couple of good FOSS environments.
Firefox can't render a damned favicon with the resources that Smalltalk used.
Everything you're doing now either was or would have been insanely expensive in 1983.
Emacs used to be derided as being an acronym for "eight megabytes and constantly swapping".
Sure, a big deal on a Sun3 with 4 megs of RAM.
It wasn't the price of RAM that made Smalltalk expensive.
You may not like the choices they made. Fine. But stop assuming that it was from ignorance or incompetence. It wasn't.
1) comparable with c++ in terms of speed
2) had extremely fast compilation times
3) easy to use, learn and familiar looking, for quick engineer buy in
4) easy to write concurrent & parallel work with
5) designed for tooling & network applications
6) batteries included
Among many, many others. Neither is Go an hammer, nor is everything a nail. For the use cases Go was designed for, I am yet to use a language as pleasant to work with as Go.
2) This is a complete non-issue -- with Google infrastructure, it's enough to not be significantly slower than C++, which is really a low bar.
3) Go is definitely easier to use than C++, I agree. That said, it also has enough of idiosyncrasies to make it familiar mostly to people used to writing Plan 9 C, starting from "nil" instead of "null", and ending with "dial" instead of "connect".
4) I never noticed how it is any easier to do it than in, say, Java. Most of the large Go programs I've seen tend to leak goroutines, for one thing.
5) Maybe it was designed for these, though I don't quite see the way it's better suited for network applications than, say, Java.
6) It's also a total non-issue at Google.
I have a year of experience writing Go tooling and network applications at Google, and it definitely wasn't enough for me to see the light. The rest of my team had quite similar experience (except of one guy who was a Go fan already before joining the company), and we would often make fun of Go's inconsistencies, idiosyncrasies, and the whole NIH approach of the language authors and maintainers.
Go is not bad language, it would have been great if it was 1989, and your only serious alternative was writing ANSI C. Unfortunately, it's been almost two decades since the 80s, and we figured out some things in the meantime. We now know how to do generics correctly, for one thing, and we already understood that null pointers have been a billion dollar mistake. The worst sin of Go though is that in the true "worse is better" spirit of Unix, it filled a gap for a better C++ by being only marginally better, taking away space for other, actually better contenders that don't happen have a billion dollar company backing them.
I think it ended up being 1) not sufficiently low-level, and 2) a bit too insular in its ecosystem, to really fill that niche. Which is what allowed Rust to seriously contend for it, and I think Rust is going to be the winner.
You need to learn more languages (and really learn them).