You see something similar with CL and Clojure (but the latter to a lesser extent): these abstractions are so powerful that those that grok them are able to construct things that others have little chance of understanding without a significant investment in time (if at all). Go does more or less the opposite: it tries to avoid any kind of cleverness.
There’s no fundamental objection to requiring people to master difficult concepts in programming: see the ubiquity of the LeetCode Hard interview. Why then is this such a barrier to the adoption of functional programming and sophisticated type systems?
Because the benefit of the "smart" approach vs the "simple" approach is usually smaller than its cost.
The cost being: Having to hire especially talented developers and developers spending more time reading and understanding code. And there is the hard-to-measure but insidious aversion of software developers to work on code that will require effort to understand.
Thing is, the "smart" approach can often be the simplest in the long term. What gets sold as "simple" to newcomers only adds technical debt which ultimately becomes even harder to survey and understand.
Because there are many alternatives that at first sight seem both easier to master and more productive. This results in perceived lower initial cost of development.
True. It's so nice to just have them in the language though. Because then the whole library ecosystem is using the same abstraction, making it far more useful.
