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