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
6. Its GUI options are so bad that Electron is a popular choice for making GUIs for it.
7. Reinvents the C runtime so that if you want to link against C code you need to have 2 runtimes, thus creating Java levels of non-interoperability.
8. Encourages highly concurrent code through goroutines but provides no isolation between them, creating a security minefield.
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.
> 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.
I disagree. I think Go brings a *lot* to the table—for businesses.
* Short learning curve means you can hire without caring if applicants know Go, driving down salaries
("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 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.
A social network for the 19A0s.