5 ms·

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

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?

KirinDave 9y ago
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.
- remus 9y ago
  > 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.
  - tmaly 9y ago
    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.
    - KirinDave 9y ago
      Why would this be beneficial unless you're also paying Google to host your software?
  - KirinDave 9y ago
    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.
  - stouset 9y ago
    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.
    - KirinDave 9y ago
      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.

KirinDave 9y ago

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.

remus 9y ago
> 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.
- tmaly 9y ago
  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.
  - KirinDave 9y ago
    Why would this be beneficial unless you're also paying Google to host your software?
- KirinDave 9y ago
  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.
- stouset 9y ago
  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.
  - KirinDave 9y ago
    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.