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

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

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

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

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.

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.

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

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.

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.

Self imposed fault, by ignoring computing history since 1976.

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.

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

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!

I used go for about 3 years, so yeah I understand... but I can't believe you actually like copy-paste/codegen more than actual native language facilities. Mind blowing to be honest.