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.
@freakazoid Probably just a). If Google had claimed to have invented Python, people would be all over that, too.
> 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 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.
@freakazoid Can't rule it out, either.
@drwho I do wonder if this is why they hired Guido. They clearly believed in Python at some point but I guess they weren't able to get what they wanted out of the community. Which very well have been more of a focus on scalability, something that would benefit only a very tiny fraction of users while potentially making Python less usable for the vast majority.
@drwho In particular, going to fine-grained locking would make Python able to use multiple cores while making single-threaded code slower and the interpreter and probably extension modules more complex.
re: Go snark
@freakazoid That was kind of my thought, too. They were trying to either get hold of something or keep something away. Wasn't sure which.
I'm not a huge fan of #golang, for some of the reasons you mentioned and for some different ones (a primary aim seems to be making devs more replaceable, which I'm not on board with).
> Promotes non-free software by making distribution of binaries without source easy
I'll say that there *are* a lot of advantages to being able to distribute free software as a statically linked binary too—it's something I like a lot about #rust development
@codesections Yeah that one is kind of a stretch.
> 2. Slower than java and has GC pauses
Really? I've always read the opposite.
The go GC has improved a lot...
Now the GC pause can take less than 200us (in go 1.5 the same task took 30ms)
Read more about the GC here:
(By the way, I've only looked at the graphs, I should read it too)
@ranfdev Sure, better than it was, but still at least as bad as Java.
@ranfdev Oops, turns out I'm wrong. I didn't realize how much Java had stagnated. Well, scratch that one off the list.
Incremental GC does have a pretty big overhead, though. Low-latency GC overhead can be up to 50%. Which is not a big deal compared to, say, Python's reference counting, but it is compared to Rust without GC. And scanning the heap uses a lot of memory bandwidth, making large heap sizes impractical.
A social network for the 19A0s.