6 ms·
Go was so obviously designed by Googlers, for Google. After the initial release, outside adopters would frequently report issues where Go undermined their produ
by dmit 7y ago
Go was so obviously designed by Googlers, for Google. After the initial release, outside adopters would frequently report issues where Go undermined their productivity. And every time the core team's response was the same - complete disbelief.
"Dependencies? What? Do you not vendor every single library you depend upon in your monorepo?"
"Advanced type system? Why? Do you not hire thousands straight out of college, and expect employees to stay put for 2-3 years (give or take)?"
Every single issue that was raised in the past 10 years was met with such incredulity.
Rob Pike, Robert Griesemer, Russ Cox - they've done a tremendous job. A great, stunning achievement for their employer. The more of the infrastructure transitions to Go, the less money Google will need to spend on people in the long term. Those three have earned billions for their company, no doubt.
And none of that means Go is a great language for your 12-person team working on a CRUD web app.
The Zen of Go is not reducing your problem to "can it be put in an array?" or "can it be put in a hashmap instead?"
The Zen of Go is looking at individual persons and deciding whether it's net positive to cut them now, or 6 months from now, after their next performance review.
- hellcow 7y agoYour comment is unfair. I've been programming for more than 20 years. I've learned many languages including C, Objective C, Java, Python, Ruby, JS, and some Haskell. I've never worked at Google. Go is my favorite language of them all and has been since I started using it almost a decade ago. I use it for personal projects, and I use it at my company. It helps me and the teams on which I've worked write correct code quickly the first time. The code we write is incredibly reliable in production at scale. It's easy to read and debug years later. Binaries can easily be compiled and deployed on any system without messing with dependencies or cross-compiler toolchains. The same properties of the language which helped Google have helped me and many thousands of others as well.
- dmit 7y ago> The same properties of the language which helped Google have helped me To be fair, I don't think anything I wrote contradicts that. If your goals align with Google's, great.
- crystaldev 7y agoMaybe those goals are more mainstream than you think (such thoughts don't lead to top comments, however).
- 0xFACEFEED 7y agoThen why couple those goals to Google instead of ascribing them to a broader philosophy that Google happens to be adopting (among many others)? Your original comment read like you were salty that Go didn't adopt ideas that enhanced yours and others productivity. Instead of writing it off as a philosophical difference (that can be attributed to any language with philosophical ideals), you have to take it to the next level with some kind of "Go devs only care about Google's needs" conspiracy. I've seen this kind of thing a lot over the years. Why can't people just agree to disagree?
- monocasa 7y agoBecause the entire governance board of golang is Google employees, and if your use case is different than there's they become outright hostile?
- 0xFACEFEED 7y agoYou'll have to back that up. Unless you interpret every rejection of an idea as hostility.
- stouset 7y agoI think it’s more “the rejection of every idea”.
- innocentoldguy 7y agoI thought dmit's comment was fair. I've been programming for over 30 years now and Go is my least favorite language (actually, I absolutely hate it). The reasons for my distaste are basically everything dmit just mentioned (and more). I get that some people love Go but that doesn't mean the criticisms against it aren't fair.
- yawaramin 7y ago> I've learned many languages including C, Objective C, Java, Python, Ruby, JS, and some Haskell. You've learned basically the same language over and over again: Algol-family imperative-OO-mishmash. Haskell is probably the most unique out of all of them, and I'm inclined to think you haven't gone too far with it. Perhaps you know SQL though and recognize how a relational (roughly, set-oriented) language can work. My point is that I understand that Go offers you some compelling advantages. We're just saying that other languages offer some pretty amazing things too, and they are even better designed (as languages) than Go. Check out this fantastic talk by Scott Wlaschin to get a sampling of truly different language paradigms and how they approach problems: https://youtu.be/0fpDlAEQio4 https://youtu.be/0fpDlAEQio4
- hellcow 7y ago> We're just saying that other languages offer some pretty amazing things too, and they are even better designed (as languages) than Go. I agree that many languages have interesting features. Your point however is not at all the argument the GP was making, which was that Go suits only Google, junior developers, and huge teams.
- deleted 7y ago[deleted]
- dx87 7y agoThat attitude is why I never bothered to learn it. Shortly after its 1.0 release, there were a bunch of "here's the good and bad about Go" posts. I remember seeing a post by Rob Pike on reddit where he said he was tired of people being on the fence about Go, and if they don't love it, they should just learn something else. That kind of "love it or leave it" attitude was prevalent everywhere, and it was a big turn off. It felt like instead of Go being designed as a tool for programmers to use, programmers were the tool, and Go was designed as a way to change them so they'd be better at what Google wants.
- pm90 7y agoThat might be how you “feel” but it doesn’t reflect the facts. The go community has been incredibly welcoming, the process for introducing new features in go is fully transparent and in the open. If you link to the reddit post we could all see what he actually said. Go is a very opinionated language for sure. Every language will be inundated with people who want their pet feature to be implemented in it and will hate on it otherwise. I am happy that the language development is not directed by such kinds of folks.
- hitekker 7y ago> That might be how you “feel” > The go community has been incredibly welcoming. Jeez, what a disconnect.
- rlonn 7y agoGolang chooses to avoid feature creep. This seems to annoy some people to no end and so these discussions always devolve into whining about feature X, Y or Z that would have made Golang soooo much better and OH how nasty are [Google or whomever] that blocks all these fantastic ideas from being implemented. If only they listened to all the smart people out there (especially me) it would have made Golang awesome and we'd see a million flowers bloom. Please stop, it's tiresome.
- cy_hauser 7y agoI know. Go was born perfect. That anyone might like Go but think it could be better by changing it disgusts me too! All you whiners -- if you like Go but think it could be made better then please use another language.
- maximente 7y agomy hypothesis was that as the world has moved forward, Google has accumulated legions of C++/to a lesser extent Java/C experts that they needed to corral into modern software engineering, to include programming languages. Go is exactly that - good enough - in part due to: - has enough C-like syntax to keep the old "this doesn't look like C/C++" guard muzzled (as opposed to e.g. Java) - avoids some of the huge C++ productivity land mines (no package management, divining which Boost version to use, build systems, etc.) - has a 21st century standard library (net/http as a first class citizen as opposed to whatever the C/C++ ecosystem "offers") - fast enough and memory performant enough, whilst exposing pointers, unsafe ops, and C interop should the need arise i think most of the above are mind tricks to get the C++ crowd to complain slightly less while increasing productivity multi-fold.
- geodel 7y agoWhat you said is more or less reasonable, except perhaps this 'Advanced type system' thing. It is bit of of a circlejerk of people for whom programing is destination and not a means to develop products.
- jeremysalwen 7y agoAs someone working at google, I had never written go code, but I had read quite a bit about how how people didn't like it on places like hn. My impression was that even though personally I would strongly prefer a more typed language like rust, the deficiencies of go were probably overblown. Then I recently had to write a small amount of go code... and I found out that go doesn't support enums....... what??? Just blew my mind.
- 0xFACEFEED 7y agoThere's a huge discussion here, if you're interested: https://github.com/golang/go/issues/19814 https://github.com/golang/go/issues/19814 TBH I thought adding enums was a cut and dried case until reading through some opposing opinions. Now I'm not so sure.
- stouset 7y agoIn other words, go has somehow managed to shoehorn themselves into a language so rigid that adding pretty basic correctness features comes with serious downsides. This is not a selling point for the language.
- arm64future 7y ago>The Zen of Go is looking at individual persons and deciding whether it's net positive to cut them now, or 6 months from now, after their next performance review. Your conclusion is nothing more than a hilarious ad hominem attack on the language.
- coryrc 7y agoI think it was the easiest way to get around Google's line limit restrictions on Python. Okay, that's probably not the real reason, but I'm not joking that this would be the easier way :).
- erik_seaberg 7y agoVendoring prebuilt deps (jar/so/dll files) is the Right Thing. Anything else creates an extra point of failure that could prevent you from going to prod or reproducing an old build. Some take this seriously enough to vendor the exact toolchain as well.
- dmit 7y agoI meant vendoring the source code of dependencies when I wrote the parent comment, but it appears you feel strongly about going one step further? Vendoring arch-specific binaries? What is the benefit of doing that, in your opinion?
- erik_seaberg 7y agoI just don't want to be in the business of maintaining our copy of someone else's toolchain and constantly rebuilding code that my team never edits. For non-java I could be talked into in-tree headers and moving native libs to a private deb/rpm repo.