1. Controlled by a single company whose business is surveillance and which has added surveillance "features" (for example it fetches packages from their cache by default)
2. Slower than Java and has GC pauses
3. Promotes non-free software by making distribution of binaries without source easy
4. Its devotees insist on reimplementing things that already have perfectly good implementations
5. Mostly worthless type system that doesn't prevent null pointer accesses
I don't believe Go was deliberately created as an attempt to gain a bunch of control and goodwill of community developed software, or as an attack on Python. But I do believe these goals are part of the reason Google has invested so heavily in it while attempting to deprecate Python internally.
My point is not that Go is terrible in terms of features or that some other language is in every way superior. It's that Go doesn't bring enough to the table to justify the fragmentation it has brought to open source. It would almost certainly have been unsuccessful had it come from almost any other source. I suspect most people who adopt it do so because a) Google and b) curly braces.
("advantages" of go, cont'd)
* "only one way to do it" means programmers all write the same code, making them all more replaceable
* dependency management/fast compile times makes it easier to throw large teams at a project without people getting in each other's way (as much)
Now, *I* don't like those features. For the sort of work I do, they're anti-features, in fact. I wish golang did not exist. But I don't think companies are embracing it illogically, or as a fad.
@codesections I haven't seen embracement of Go happen top-down at any company other than Google. This seems true of pretty much any "non-enterprise" language, i.e. anything other than C++ or Java. Engineers push for it because fad, then companies embrace it because it helps them seem cool and innovative.
@codesections You make a really good point, though, not just about Go but about "readable code" generally. Google even has a "readability review" process which requires a certified readability reviewer.
But I do believe that languages should be learnable and code should be readable. Perhaps it's not so much about readability as it is about designers deliberately limiting the expressiveness of PLs to trade off elegance and conciseness for interchangeability.
@codesections So instead of a gentle path leading up a high mountain, which is what I'd like to see, you have a low mesa where most people can easily get on top but they're never gonna see very far.
Sounds so very Google-ish.
@codesections Sorry, the correct term is "Googley".
But now this makes me think I should be using Haskell, Racket, Clojure, or some other extremely expressive language. Not that my Python code doesn't tend toward similar levels of expressiveness. I did just write a small parser combinator library for a relatively simple parsing problem.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.