Hacker News Reader

Comment by toprerules | Hacker News Reader

But by pushing complexity into third parties, the vast majority can benifit from a smaller spec and less cognitive load. It's a trade off for sure, but I think as a language designer you have to be careful not to let the 1% convince you that the 99% needs x feature. There are tons of existing Go projects that are working just fine as is. How many of them really need more than what exists already?

View on HN

A formulation of this argument has been used since the 1970s and it keeps being proven wrong over and over as progressively people realize the ML and Common Lisp folks were right. Those features are not bullshit invented to make a mathematician happy, they're features that make code safer, more concise, easier to reason about, and easier for optimizers to turn into performant code.

Why is it that folks keep trying to formulate this as "the egghead 1% vs the sane 99%?" Stuff is constantly flowing out of academia and advanced production labs and our industry re-levels to that. It's the way a growing industry is supposed to work.

Go is not a good language in a technical sense. It's an expression of Google's business needs. Google's got 0 interest in making rank and file programmers better; they're tuned for revolving door recruiting on a massive scale. For them, their goal is to make programmers who only have domain knowledge and require no training. They're not even that interested in lowering shipped error rates; they have a ton of machinery and a whole legion of SRE folks to help manage deployments when testing is minimal and hand-written.

To be clear btw, I am not condemning Google for arriving at this conclusion. Their economics are totally different from everyone else's. Every Big Company(tm) has a unique angle of attack on the training problem. Ironically, google's SRE folks are aggressively in the opposite camp in terms of recruiting and practice because they're the ones who actually have to enable this model of shipping broken code safely.

Everything about Go is designed to maximize what Google wants out of mid-experience programmers. It's so weird how non-google people seem to find this state of affairs good, as they almost certainly cannot afford to do it this way.

> Everything about Go is designed to maximize what Google wants out of mid-range programmers. It's so weird how non-google people seem to find this state of affairs good.

If it let's them build products that serve billions of users in ways that that were completely inconceivable even 30 years ago then maybe it's not such a bad tradeoff. To be clear I'm talking more about the philosophy that produced go, not so much the language itself. Obviously Google is more than go.

How does this only benefit Google? Other businesses can surely benefit from this aspect of Go. Heck if your an aspiring startup that has to hire new people, you gain from this.

Why would this be beneficial unless you're also paying Google to host your software?

As I suggested, it's not inherently bad but it's functioning at a scale that simply isn't replicatable by most orgs.

If you think that approach can work for you in your job and that job is not at once of the top 10 tech find? Write an experience report about how you made it work.

That's his point. It's not a bad tradeoff... for Google. It might be a bad tradeoff for you, if you don't (according to his thesis) have a revolving door of mid-level engineers lacking domain knowledge and/or a large fleet of SREs.

Just an aside, it's slightly opposite from what you said. Google doesn't want software engineering at a larger scale to enter into the world of domain specific folks at all. So they specialize in giving domain specific folks a very tight coupling to the computer without a care in the world for most anything other than a narrow band of parameters.

They very much have an org for generating software that treats domain specialists as pluggable domain optimizers. Architects and SRE all enable that.

Given the features of Go, Google could have used Algol 68 instead, or Active Oberon just to refer something modern, and still make those wonderful products you mention.

Which are still a minority compared with the amount of Google products written in Python, Java, C++ or even Dart.

So, all the products were already conceivable in some 30 year old languages.

Reply on news.ycombinator.com