4 ms·

That's saying the same thing. If you give someone the ability to understand a brilliant language, they will turn their attention to the language and away from t

That's saying the same thing. If you give someone the ability to understand a brilliant language, they will turn their attention to the language and away from the problem. That's just human nature. Shiny attracts us. Let's be honest, we all have way more fun diving deep into crafting the perfect type in Haskell. But Pike indicates that if you constrain developers to bounds that they already know, where they can't turn their attention to learning about what is brilliant, then they won't be compelled away from what actually matters – the engineering.

alpaca128 2y ago
Is there any evidence that the Go style of constraints increases productivity or code quality or other metrics compared to "shiny" languages? I've heard that point repeated many times, but people have done a decent amount of engineering in many other languages too, without the need to be limited like that.
- randomdata 2y ago
  I expect nobody outside of Google has ever truly taken the time to study it. When was the last time you saw a programmer actually research the effectiveness of their tools and not just land on "I like this. It feels right." I never have! But I'm not sure it matters. Go was created to test the theory, not because a theory was proven. It didn't have to be successful. It may be that the studies didn't happen even within Google, although that is our greatest chance. We do know Google actually cares about data, unlike programmers. That said, since Go was released it seems every other language has tried to copy it with their own twist, so while that may not come from a place of evidence, it would appear that the feeling of increased productivity[1] was felt. [1] Or something adjacent. Focusing on engineering isn't necessarily about productivity. You can't discount productivity, but it is not the top engineering concern, especially in a place like Google.
  - wyager 2y ago
    > since Go was released it seems every other language has tried to copy it What are you referring to here? I would consider myself quite well-apprised of recent developments in PL theory (and practice) and I am struggling to come up with examples matching this description. Go's main selling point, at least as of 10 years ago, was its green threading system, and even at the time it was substantially inferior to the green threading systems available in BEAM (Erlang, Elixir) or GHC Haskell
    - Mawr 2y ago
      - Java's latest addition of green threads is 100% lifted from Go. - Rust and Zig's built-in language tooling, including dependency management and an opinionated autoformatter. - Java's ZGC was an obvious response to Go's GC. There's also the realization that the fewer GC knobs there are to tune the better. - Possibly Java's quest to add value types as well, not 100% sure on the timeline. - Broad industry trend towards providing easy cross compilation into static binaries.
      - instig007 2y ago
        > Java's latest addition of green threads is 100% lifted from Go. or gevent, or many other greenlet implementations across languages, 100%
      - wyager 2y ago
        > Java's latest addition of green threads is 100% lifted from Go. Why do you say it was lifted from Go and not from one of the places Go lifted it from, like the two I mentioned? > Rust and Zig's built-in language tooling Maybe my memory is failing here, but I don't recall rust ecosystem tooling ever lagging behind Go's. The opposite, if anything. > Java's ZGC/value types Can't comment on this one, could be right, although are any of these things clearly sourced from Go? Not disagreeing, I just don't know the history here. I'm willing to believe that Java is copying from Go, because it's one of the most lumbering languages in popular use today. > Broad industry trend towards providing easy cross compilation into static binaries. I'm pretty sure Go does't get credit for this one either. This has been happening independently across many ecosystems as a natural response to increasing containerization and falling storage costs.
instig007 2y ago
> then they won't be compelled away from what actually matters – the engineering. Maybe it is, to the extend that playing with lego blocks authorised by the lego corporation is considered engineering. That, of course, is a silly line to draw for defining the discipline. > we all have way more fun diving deep into crafting the perfect type in Haskell What Haskell allows you to do in practice is defining required and missing control flows (for solving your problems) as types[0], and constraining those types with rules that define your business domains the control flows must operate in. That is the actual engineering, as opposed to joining plastic bricks. [0] https://hackage.haskell.org/package/foldl-1.4.17/docs/Control-Foldl.html#t:Fold https://hackage.haskell.org/package/foldl-1.4.17/docs/Contro...
- randomdata 2y ago
  > What Haskell allows you to do in practice is defining required and missing control flows It allows that in theory, at least, certainly. That's the whole reason for its existence. But in practice, developers become enamoured with the language and start to forget about the problem. If that weren't a problem we'd all be using Haskell, but back in the real world.
  - School-Cotton 2y ago
    The reason we’re not all using Haskell is because like any language it has pros and cons and isn’t the best choice for every niche. Not because “developers become enamored with the language and start to forget about the problem”. Anyway, why do Go fans always reach for the Haskell strawman in discussions like this? Most mainstream languages are not nearly as exotic as Haskell, while also not being intentionally crippled like Go. But for some reason Go fans always want to compare it to Haskell. Even JavaScript, Python and Java are not allergic to adding modern features like iterator map/filter/etc., do you think those are esoteric ivory tower languages too?
    - randomdata 2y ago
      > The reason we’re not all using Haskell is because like any language it has pros and cons and isn’t the best choice for every niche. Exactly. Thanks for reiterating. > Anyway, why do Go fans always reach for the Haskell strawman in discussions like this? What's a Go fan? Someone who thinks that Go blows? That is as bizarre as becoming enamoured by a language. What leads one to have feelings about a language anyway? It is an impossible to understand concept for me. > Even JavaScript, Python and Java are not allergic to adding modern features like iterator map/filter/etc. In what world are patterns from the 1960s "modern"? Do you consider selt belts in cars to also be a modern feature?
School-Cotton 2y ago
> If you give someone the ability to understand a brilliant language, they will turn their attention to the language and away from the problem. That's just human nature. Not sure which languages you define as brilliant but I’ve never seen this pattern anywhere in my career, in any language. Including Rust, which is often offered by Go fans as an example of an esoteric exotic language. In everywhere I’ve seen, people are focused on solving some engineering problem, not on showing off their brilliance by solving language puzzles. This defense of Go is REALLY common but as far as I can tell is purely based on myth.
- randomdata 2y ago
  > I’ve never seen this pattern anywhere in my career Me neither, but I've never actually tired to look. In honesty, have you? It is not exactly to the faint of heart to study. I suspect only Google is willing to go to the necessary depts. But, if you know of something otherwise, I'm sure we're all interested in the details. > This defense of Go is REALLY common but as far as I can tell is purely based on myth. 1. Defence? Are you in some kind of fight...? That doesn't make any sense. 2. Myth? Are you confusing the hypothesis on which Go was built with results of experimentation? It very well may be that the hypothesis didn't stand up to experimentation, but what does that have to with our discussion? Furthermore, if you really want to change the subject to talk about that, why have you failed to tell us anything about the details of experimentation?
mikeschinkel 2y ago
I recognized exactly that way back in 1995. I used to teach Clipper in the late 80s and early 90s and you could do so much with it. It's competitor was FoxPro, which was far less capable. However, in hindsight after I quit using it I realized that Clipper developers often focused on perfecting code — myself included — whereas FoxPro developers just got shit done for the client/end-user. #fwiw

alpaca128 2y ago

Is there any evidence that the Go style of constraints increases productivity or code quality or other metrics compared to "shiny" languages? I've heard that point repeated many times, but people have done a decent amount of engineering in many other languages too, without the need to be limited like that.

randomdata 2y ago
I expect nobody outside of Google has ever truly taken the time to study it. When was the last time you saw a programmer actually research the effectiveness of their tools and not just land on "I like this. It feels right." I never have! But I'm not sure it matters. Go was created to test the theory, not because a theory was proven. It didn't have to be successful. It may be that the studies didn't happen even within Google, although that is our greatest chance. We do know Google actually cares about data, unlike programmers. That said, since Go was released it seems every other language has tried to copy it with their own twist, so while that may not come from a place of evidence, it would appear that the feeling of increased productivity[1] was felt. [1] Or something adjacent. Focusing on engineering isn't necessarily about productivity. You can't discount productivity, but it is not the top engineering concern, especially in a place like Google.
- wyager 2y ago
  > since Go was released it seems every other language has tried to copy it What are you referring to here? I would consider myself quite well-apprised of recent developments in PL theory (and practice) and I am struggling to come up with examples matching this description. Go's main selling point, at least as of 10 years ago, was its green threading system, and even at the time it was substantially inferior to the green threading systems available in BEAM (Erlang, Elixir) or GHC Haskell
  - Mawr 2y ago
    - Java's latest addition of green threads is 100% lifted from Go. - Rust and Zig's built-in language tooling, including dependency management and an opinionated autoformatter. - Java's ZGC was an obvious response to Go's GC. There's also the realization that the fewer GC knobs there are to tune the better. - Possibly Java's quest to add value types as well, not 100% sure on the timeline. - Broad industry trend towards providing easy cross compilation into static binaries.
    - instig007 2y ago
      > Java's latest addition of green threads is 100% lifted from Go. or gevent, or many other greenlet implementations across languages, 100%
    - wyager 2y ago
      > Java's latest addition of green threads is 100% lifted from Go. Why do you say it was lifted from Go and not from one of the places Go lifted it from, like the two I mentioned? > Rust and Zig's built-in language tooling Maybe my memory is failing here, but I don't recall rust ecosystem tooling ever lagging behind Go's. The opposite, if anything. > Java's ZGC/value types Can't comment on this one, could be right, although are any of these things clearly sourced from Go? Not disagreeing, I just don't know the history here. I'm willing to believe that Java is copying from Go, because it's one of the most lumbering languages in popular use today. > Broad industry trend towards providing easy cross compilation into static binaries. I'm pretty sure Go does't get credit for this one either. This has been happening independently across many ecosystems as a natural response to increasing containerization and falling storage costs.

instig007 2y ago

> then they won't be compelled away from what actually matters – the engineering. Maybe it is, to the extend that playing with lego blocks authorised by the lego corporation is considered engineering. That, of course, is a silly line to draw for defining the discipline. > we all have way more fun diving deep into crafting the perfect type in Haskell What Haskell allows you to do in practice is defining required and missing control flows (for solving your problems) as types[0], and constraining those types with rules that define your business domains the control flows must operate in. That is the actual engineering, as opposed to joining plastic bricks. [0] https://hackage.haskell.org/package/foldl-1.4.17/docs/Control-Foldl.html#t:Fold https://hackage.haskell.org/package/foldl-1.4.17/docs/Contro...

randomdata 2y ago
> What Haskell allows you to do in practice is defining required and missing control flows It allows that in theory, at least, certainly. That's the whole reason for its existence. But in practice, developers become enamoured with the language and start to forget about the problem. If that weren't a problem we'd all be using Haskell, but back in the real world.
- School-Cotton 2y ago
  The reason we’re not all using Haskell is because like any language it has pros and cons and isn’t the best choice for every niche. Not because “developers become enamored with the language and start to forget about the problem”. Anyway, why do Go fans always reach for the Haskell strawman in discussions like this? Most mainstream languages are not nearly as exotic as Haskell, while also not being intentionally crippled like Go. But for some reason Go fans always want to compare it to Haskell. Even JavaScript, Python and Java are not allergic to adding modern features like iterator map/filter/etc., do you think those are esoteric ivory tower languages too?
  - randomdata 2y ago
    > The reason we’re not all using Haskell is because like any language it has pros and cons and isn’t the best choice for every niche. Exactly. Thanks for reiterating. > Anyway, why do Go fans always reach for the Haskell strawman in discussions like this? What's a Go fan? Someone who thinks that Go blows? That is as bizarre as becoming enamoured by a language. What leads one to have feelings about a language anyway? It is an impossible to understand concept for me. > Even JavaScript, Python and Java are not allergic to adding modern features like iterator map/filter/etc. In what world are patterns from the 1960s "modern"? Do you consider selt belts in cars to also be a modern feature?

School-Cotton 2y ago

> If you give someone the ability to understand a brilliant language, they will turn their attention to the language and away from the problem. That's just human nature. Not sure which languages you define as brilliant but I’ve never seen this pattern anywhere in my career, in any language. Including Rust, which is often offered by Go fans as an example of an esoteric exotic language. In everywhere I’ve seen, people are focused on solving some engineering problem, not on showing off their brilliance by solving language puzzles. This defense of Go is REALLY common but as far as I can tell is purely based on myth.

randomdata 2y ago
> I’ve never seen this pattern anywhere in my career Me neither, but I've never actually tired to look. In honesty, have you? It is not exactly to the faint of heart to study. I suspect only Google is willing to go to the necessary depts. But, if you know of something otherwise, I'm sure we're all interested in the details. > This defense of Go is REALLY common but as far as I can tell is purely based on myth. 1. Defence? Are you in some kind of fight...? That doesn't make any sense. 2. Myth? Are you confusing the hypothesis on which Go was built with results of experimentation? It very well may be that the hypothesis didn't stand up to experimentation, but what does that have to with our discussion? Furthermore, if you really want to change the subject to talk about that, why have you failed to tell us anything about the details of experimentation?

mikeschinkel 2y ago

I recognized exactly that way back in 1995. I used to teach Clipper in the late 80s and early 90s and you could do so much with it. It's competitor was FoxPro, which was far less capable. However, in hindsight after I quit using it I realized that Clipper developers often focused on perfecting code — myself included — whereas FoxPro developers just got shit done for the client/end-user. #fwiw