I think the point they're making is that the Go community is unusually pitchfork-ey. Having used Go since pre-1.0 days, I certainly agree; there's a very strong sense of, "if you want <feature X>, you're doing it wrong" - despite legitimate concerns, like the ones outlined in this article.
It reminds me of the Java community when Sun stopped adding significant features for years after 2004. Every feature which wasn't added was widely considered by most Java developers as being in the name of protecting us from ourselves. When Java 8 came out suddenly some of those bad/evil features became flavor of the week. There's a tendency to try and convince yourself that the language designers made the best decisions at every turn, which isn't a healthy way of thinking critically.
I've heard this same criticism levelled at the Clojure community, as well.
Honestly, I can't think of any language community that's developed such a reputation for pitchforkiness towards suggestions as the Go and Clojure communities.
What a strange argument. The difference is that clojure is about as extensible a language as it's possible to have.
A macro system in a homoiconic language allows you to implement many types of semantic sugar or things that would be full-on 'language features' in other languages as a simple library. See core.async: https://github.com/clojure/core.async
Make sure to expand all of his posts on the thread, because he goes back and forth for a while.
Much of it has to do with the community's attitude towards macros: there's an attitude of "macros are bad and you shouldn't use them", and people who write macros are often jumped on by the community.
Here's one sentence of Steve's that sums it up:
> When people announce: "hey, I made a loop macro!" the response absolutely can NOT be: "why can't you just write it as a series of maps and reductions?"
And another:
> If Clojure people all said "of course you can use macros! Of course you can use CL-style loop facilities! It's your code, do what you like! Feel free to use nonlocal exits all you like!" -- well, then it would be a lot closer to a Yes language.
The problem is the way the community treats people who don't follow the prescriptive norms of the core Clojure people (norms which are often in conflict with the broader Lisp community).
The Clojure developer had a certain vision for a new language - otherwise he could have just continued to use Lisp (which he earlier used for a few years). It might be useful to respect that and develop Clojure along this vision.
Something like Common Lisp follows a different vision. Common Lisp was a large community effort and the language EXPLICITLY had been designed to be morphed by the user into widely different shapes. That's why it reserves characters to the user, why it has a programmable reader, why it has procedural macros, ..., and why CLOS has a Meta Object Protocol. Probably that was also too much flexibility.
But even with Common Lisp, because it gives you little guidance how to use it and there are a gazillion programming styles possible, you need to develop taste. You can design ugly code and extensions and you can learn to develop better code and extensions. Common Lisp supports LOOP, because it was already there (it was introduced with Interlisp in the 70s, then brought to Maclisp and Lisp Machine Lisp) and there wasn't a better alternative at that time.
The 'best' iteration construct in the Lisp world is Jonathan Amsterdam's Iterate. But that would also not fit well into Clojure... But Iterate fits well into Common Lisp and works nicely as an alternative to LOOP.
