3 ms·

> made by morons for morons The creators of Go have also built the foundation of everything you take for granted. The real "harsh truth" here, of course, is th

by tucnak 2y ago

> made by morons for morons The creators of Go have also built the foundation of everything you take for granted. The real "harsh truth" here, of course, is that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry, such that the likes of Rust "death by committee" people may only dream of. The long-lasting obsession that Rust people have with Go and the Go team has become a meme. Borgo is the recognition of that: a handout to Rust people that they will never appreciate.

desumeku 2y ago
People seriously act like Rob Pike's quote was about appealing to the lowest common denominator of programmers possible without realizing that the functional programming concepts they hold so dearly have been lacking for 50 years in the world of C/C++ where it's creators came from. They are so quick to frustration over the fact that the some languages don't act like they think it should and don't require the extraneous baggage of higher-order programming in order to quickly be productive in, while at the same time the entire operating system their computer runs on contains not a single line of map(), reduce() or filter().
- tucnak 2y ago
  For a community supposedly "committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience"[1] Rust activists perhaps unsurprisingly lack in tolerance, empathy, and awareness. The community has changed, too. I liked them more circa ~2015 from before the corpos caught on to "the most loved" language, and have since blown evangelists' expectations for future adoption way out of proportion. As long as the drawn-out vendetta lead by Rust activists contra Go is concerned, old proverb comes to mind: "Hating popular things does not make you interesting." [1]: https://www.rust-lang.org/policies/code-of-conduct https://www.rust-lang.org/policies/code-of-conduct
- skinkestek 2y ago
  > They are so quick to frustration over the fact that the some languages don't act like they think it should and don't require the extraneous baggage of higher-order programming in order to quickly be productive in Higher order functions often seems to be a way to complicate otherwise easy to read code. Kotlin manages to do it reasonably well, in Javascript I has beem behind some of my absolutely worst debugging experiences. The problem with Go, as far as I have seen is not about functional programming, but rather about things like making a point out of not supporting generics for years. For anyone who has experienced the Java 1.4 to Java 5 transition, and all the cruft it removed I cannot see how any of them can willingly accept a language that made a point out of being clumsy so one had to do it the old clumsy way agaim. Or how a language that us supposedly a good fit for web backends had (don't know if it have now, I've given up) no simple way in the standard library or any popular templating solution to say in a template that it should be included in a bigger template, thereby forcing the code to know about things that belong in the design world. I.e. to have - a common header with dynamic title - a dynamic part between - and common footer the correct way last I checked seemed to be to string them together like a php script from the late nineties.
cwalv 2y ago
> The creators of Go have also built the foundation of everything you take for granted Is it the foundation because it was built a long time ago, and is "good enough" .. or because it's just really good? "Worse is better" comes to mind. There was another post on hn today about "pipelines getting stuck" that was really just about poor interaction between pipelines and programs changing their buffering behavior based on `istty()`. bash has been around a long time, and will stay around for a long time still, but that doesn't mean its design leaves nothing to be desired. It just means the benefits of changing it haven't crossed the 10x threshold of the costs (partially because it's foundational).
erik_seaberg 2y ago
Fitting a C compiler on a PDP-11 was an impressive achievement, but as a language it was a poor foundation to build anything reliable, and we still live with the consequences.
- pjmlp 2y ago
  Especially taking into account the decade of systems languages predating that feat, and everything else happening outside Bell Labs. Had UNIX been a commercial product from the get go, and most likely C wouldn't have taken off as it did.
alfiedotwtf 2y ago
> that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry Those geniuses fought against implementing generics for almost 10 years.
- tucnak 2y ago
  And they were right. The generics in Go have turned out dogshite... I try to avoid them at all costs because besides simple data structures like Trees and so on, they're just more trouble. Go was not meant to have generics.
  - LinXitoW 2y ago
    It literally had generics from the very first day. They were just gate kept from the "smelly, lowest common denominator code monkey morons", because noone could match the genius of their creators, or ever have the same issues to solve as the creators (because their little brains are too tiny). It's lists, and maps.
  - pjmlp 2y ago
    Self imposed fault, by ignoring computing history since 1976.
  - erik_seaberg 2y ago
    Static typing prevents reusing functions unless they're generic. The other option is to give up static typing and pass "all" everywhere, like a dynamic language.
  - alfiedotwtf 2y ago
    > that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry > The generics in Go have turned out dogshite Pick one.
    - tucnak 2y ago
      I guess it's fine for what it enables, Tree[T] of some kind basically. But we had that with codegen already.. People who really needed trees, could do that forever. However, the issue is the "unwashed"—like they said in adjacent comment—putting them everywhere now, where an interface would be more fitting. Hopefully I'm explaining in terms that you can comprehend. This is dogshite because I have to fork a bunch of stuff to actually use it!

by tucnak 2y ago

desumeku 2y ago

People seriously act like Rob Pike's quote was about appealing to the lowest common denominator of programmers possible without realizing that the functional programming concepts they hold so dearly have been lacking for 50 years in the world of C/C++ where it's creators came from. They are so quick to frustration over the fact that the some languages don't act like they think it should and don't require the extraneous baggage of higher-order programming in order to quickly be productive in, while at the same time the entire operating system their computer runs on contains not a single line of map(), reduce() or filter().

tucnak 2y ago
For a community supposedly "committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience"[1] Rust activists perhaps unsurprisingly lack in tolerance, empathy, and awareness. The community has changed, too. I liked them more circa ~2015 from before the corpos caught on to "the most loved" language, and have since blown evangelists' expectations for future adoption way out of proportion. As long as the drawn-out vendetta lead by Rust activists contra Go is concerned, old proverb comes to mind: "Hating popular things does not make you interesting." [1]: https://www.rust-lang.org/policies/code-of-conduct https://www.rust-lang.org/policies/code-of-conduct
skinkestek 2y ago
> They are so quick to frustration over the fact that the some languages don't act like they think it should and don't require the extraneous baggage of higher-order programming in order to quickly be productive in Higher order functions often seems to be a way to complicate otherwise easy to read code. Kotlin manages to do it reasonably well, in Javascript I has beem behind some of my absolutely worst debugging experiences. The problem with Go, as far as I have seen is not about functional programming, but rather about things like making a point out of not supporting generics for years. For anyone who has experienced the Java 1.4 to Java 5 transition, and all the cruft it removed I cannot see how any of them can willingly accept a language that made a point out of being clumsy so one had to do it the old clumsy way agaim. Or how a language that us supposedly a good fit for web backends had (don't know if it have now, I've given up) no simple way in the standard library or any popular templating solution to say in a template that it should be included in a bigger template, thereby forcing the code to know about things that belong in the design world. I.e. to have - a common header with dynamic title - a dynamic part between - and common footer the correct way last I checked seemed to be to string them together like a php script from the late nineties.

cwalv 2y ago

> The creators of Go have also built the foundation of everything you take for granted Is it the foundation because it was built a long time ago, and is "good enough" .. or because it's just really good? "Worse is better" comes to mind. There was another post on hn today about "pipelines getting stuck" that was really just about poor interaction between pipelines and programs changing their buffering behavior based on `istty()`. bash has been around a long time, and will stay around for a long time still, but that doesn't mean its design leaves nothing to be desired. It just means the benefits of changing it haven't crossed the 10x threshold of the costs (partially because it's foundational).

erik_seaberg 2y ago

Fitting a C compiler on a PDP-11 was an impressive achievement, but as a language it was a poor foundation to build anything reliable, and we still live with the consequences.

pjmlp 2y ago
Especially taking into account the decade of systems languages predating that feat, and everything else happening outside Bell Labs. Had UNIX been a commercial product from the get go, and most likely C wouldn't have taken off as it did.

alfiedotwtf 2y ago

> that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry Those geniuses fought against implementing generics for almost 10 years.

tucnak 2y ago
And they were right. The generics in Go have turned out dogshite... I try to avoid them at all costs because besides simple data structures like Trees and so on, they're just more trouble. Go was not meant to have generics.
- LinXitoW 2y ago
  It literally had generics from the very first day. They were just gate kept from the "smelly, lowest common denominator code monkey morons", because noone could match the genius of their creators, or ever have the same issues to solve as the creators (because their little brains are too tiny). It's lists, and maps.
- pjmlp 2y ago
  Self imposed fault, by ignoring computing history since 1976.
- erik_seaberg 2y ago
  Static typing prevents reusing functions unless they're generic. The other option is to give up static typing and pass "all" everywhere, like a dynamic language.
- alfiedotwtf 2y ago
  > that the Go team exhibits engineering genius, taste, and particularity that is rare to find in our industry > The generics in Go have turned out dogshite Pick one.
  - tucnak 2y ago
    I guess it's fine for what it enables, Tree[T] of some kind basically. But we had that with codegen already.. People who really needed trees, could do that forever. However, the issue is the "unwashed"—like they said in adjacent comment—putting them everywhere now, where an interface would be more fitting. Hopefully I'm explaining in terms that you can comprehend. This is dogshite because I have to fork a bunch of stuff to actually use it!