Item — HN Reader

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.

7 comments

Your 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.

> 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.

Then 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?

Because the entire governance board of golang is Google employees, and if your use case is different than there's they become outright hostile?

You'll have to back that up. Unless you interpret every rejection of an idea as hostility.

I think it’s more “the rejection of every idea”.

Maybe those goals are more mainstream than you think (such thoughts don't lead to top comments, however).

I 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.

> 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

> 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.

That 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.

Golang 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.

I 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.

That 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.

> That might be how you “feel”

> The go community has been incredibly welcoming.

Jeez, what a disconnect.

Well... Go is a language that wants to be something specific, rather than be something for everyone. That means that some suggestions just don't fit, not because they're hard to implement, but because they're wrong for the language. It is very appropriate for the language designers to say "If that's what you want, then you don't want Go. There are other languages that fit what you want better; go find one and use that." That's completely reasonable and proper.

It's also possible for the language designers to say the exact same words, and be ignoring real problems with the language - problems that could be fixed within the spirit of the language.

If you go to the Haskell people and say "This language would be so much more usable by so many more people with an Algol-like syntax", they're not going to listen to your helpful suggestion. What you're asking for is something that would not be Haskell. But to those asking, they think it's a perfectly reasonable request.

I don't have a great example of the second kind, because languages with those kinds of designers typically die early.

As 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.

There's a huge discussion here, if you're interested: 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.

In 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.

my 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.

Vendoring 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.

I 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?

I 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.

I 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 :).

>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.