But the selection of features has limited value if the selection isn't coherent and the features don't compose. Within both FP and OOP there are languages whose design choices represent coherent choices with synergy... and ones that don't.
Go's feature set doesn't provide that coherence and synergy for functional abstractions. Frankly, it's an awkward obstacle in that direction. Beyond that, its feature set is deliberately designed to place arbitrary limits on abstraction.
Point free style possible in languages like Haskell and SML where the syntax makes it practical. Haskell and SML make it easy, Scala does not. If you made an OOP language with the right syntax features, you could have point-free style in that language too. You can do point-free style in Python with just a little effort. It's orthogonal to the FP/OOP debate.
"The quality of roads is relevant, but not really the answer. Bicycles can be ridden on dirt roads or sidewalks"
Bicycles can only be ridden safely on rough surfaces with good pneumatic tyres. As for the sidewalks, 1) their quality was also very variable, 2) they didn't offer a continuous path anywhere unless you only wanted to cycle around a single block (often not even then), 3) they were full of pedestrians trying to avoid the rough, filthy road surface, 4) hopping on and off kerbs is not a good idea without pneumatic tyres and a lightweight frame (early bicycles were ponderous and heavy).
The description of the technical progression needed to make the bicycle practical is fine, but the author seems to need to dismiss all previous thought on bicycles simply to justify their argument. Firstly, that's not a motivation I admire, secondly the dismissal of those obstacles and the other cited disincentives is just wrong: those obstacles were definitely there, something technical and social progress had to address before a bicycle was a reasonable and useful idea.
I'd agree with you that the feature list is more important than a vaguer title. That's something Robet Harper talks about: http://www.cambridgeblog.org/2017/05/what-if-anything-is-a-p...
But the selection of features has limited value if the selection isn't coherent and the features don't compose. Within both FP and OOP there are languages whose design choices represent coherent choices with synergy... and ones that don't.
Go's feature set doesn't provide that coherence and synergy for functional abstractions. Frankly, it's an awkward obstacle in that direction. Beyond that, its feature set is deliberately designed to place arbitrary limits on abstraction.