I think the community is open to change of the language, given that the idea you propose is a good one.
The thing that led tarcieri to write the "Erlang is a Ghetto" post was that he proposed the addition of Ruby-style blocks to the Erlang language. And then Richard O'Keefe wrote back a post—not a very diplomatic one—which explains why Ruby-style blocks is a horrendously bad idea to add to any language.
The main reason that Erlang sometimes comes along as smug is because there are some people in the community who are extremely capable in their fields of expertise. You need a good argument to convince a semanticist that your informally specified language extension is worth anything, unless you can supply meta-theorems which explains why. Or at least provide proper semantics. In other words, you need a really good design.
If you have working code for your design, it is even better. If you have an EEP (Erlang Enhancement Proposal) you may even have your idea implemented. There is, for instance, an EEP called "Named funs" which extends and generalizes tarcieris proposal. It did not go in in time for R16, but it is still being worked on.
Parameterized modules were an experiment. Like Tuple funs (now removed), packages (now removed), and mnemosyne (now removed). They still live on outside the Erlang distribution but retains enough inside to support them via parse transformations.
"
You are confronted with the problem of wasting a lot of time writing
basement level code to access and update deep values. You think "Great!
I can write DSL or combinators to solve this!". Now you got two
problems, and you haven't come any closer to solving the first one. The
DSL still maps to functions which needs to access and update these
values, and that code is still painful to write. Your next step is to
think "Great! Let's generate all that code then!". Now you got three
problems, and you better hope to have not made any error when writing
that code generator or you'll waste a lot more time. Speaking of time,
by the time you get to that point the PHP developer has already long
finished his bug-free implementation of the same code and is moving on
to other tasks."
I think the problem is that Erlang does some things extremely well, which leads to people getting a bit smug about it, in a way that sometimes reminds me of "photography purists" sniffing at digital photography as being so very clearly sub-par, a few years ago.
My reality is that for a lot of the web stuff I do, the faster development time that Rails gives me is worth way more than a bit of speed / better use of resources. I don't need a redundant site with 0 downtime, I need to figure out if there's a market for what I'm working on, and/or pivot and add features as I begin to understand things better.
+1 for Chicago Boss, though, it's a solid effort that tries to push Erlang in some interesting directions. I do think I'll be using it for a project soonish, as the specs involve a lot of piping data around, and websockets, stuff that Rails is not as good at.
I'm pretty comfortable with Erlang, actually, having used it on and off for the past 9 years. Elixir looks cool, but a bit too experimental for what I'm working on. Chicago Boss makes me a bit nervous from that point of view too, for that matter... so we'll see what route we end up taking. Evan Miller, for the record, is really great about responding to bug reports and code ideas, so that is a big plus about the project.
The community is anything but a ghetto. Everyone I've interacted with is both highly intelligent, helpful, and very opinionated about the future of the language.
One of Erlang's strengths is its stability; they get their stability from being really picky about some things.
