A stranger / corner language to win must provide a lot more than another more accessible technology.
EDIT: it does not help that other popular backend technologies suck so hard performance-wise, since I can't see how javascript is better than, for example, Ruby, as a language (but the contrary).
You are right that both Go and Node.js has a lot of mass and a lot of acceleration right now. But Erlang has inertia in the projects where it does well and it will probably not affect typical Erlang systems much if Node.js or Go grows large. To this extent, Erlang is a too different beast.
You're probably more or less correct, but turn things around: from the point of view of the Node.js user, Node does pretty much everything they need, and Erlang does "extra, cool stuff" that, however, they can live without; or think they can.
They can do fast, dynamic web sites with web sockets with relatively low overhead, and that's really what they are after.
This is related to disruptive innovation being discussed elsewhere:
https://news.ycombinator.com/item?id=7397653
So for them, node.js is "good enough".
You are I'm sure correct that people who need Erlang won't see Node encroach on their turf, but it's something of a missed opportunity for Erlang just the same.
They're blub programmers
>As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
From PG's "Beating the Averages"
And I know plenty of hipster programmers forever chasing the new language du jour who deliver little but useless abandoned libraries on github. Check out this half working haskell ORM I'm already getting sick of, oh and there's no tests
And I work next to a company that foolishly decided to write their API using scala (don't you know rails doesn't scale) and is now reduced to spending 3 months training new devs because they can't hire to save their lives.
So yeah, tell me about "blub" programmers again. I'll tell you, these "blub" programmers make the friggin' world go round. You like PG's essay but riddle me this - how many lisp startups has YC funded?
Basho uses Erlang, despite not really being able to hire erlang devs (just need to hire and train, for the most part, its a small community), because they feel it gives them a competitive advantage, and even attracts more talented developers.
I'm not arguing that you can't or shouldn't get shit done w/ node.js/Go/PHP/Java/C#/whatever works, just that its ignorant to say "Haskell/Lisp/Erlang/OCaml/Whatever has lots of weird shit I don't need".
It's funny that you call these languages the "language de jour" when Haskell, Lisp, and Erlang are all like 20+ years old.
What I can't stand is this kind of condescending smugness - "oh, you're still using X? You're a 'blub' programmer!" as if the only conceivable reason for their choice is that they're lazy, stupid, unmotivated, or all three. Well maybe it's because they like that language, they're productive in it, it's mainstream and hireable, and they don't have any unusual requirements!
I get what PG was trying to say in his essay, but I don't think he expressed it very well. Programmers should try to choose the most productive possible tools, of course. But he's made it rather too easy to simply dismiss anyone who hasn't ended up choosing the most hardcore language possible as "blub programmers", rather than acknowledging they possibly made an informed, pragmatic choice. Engineering is about tradeoffs and throwing around these labels does not improve the discussion.
In my opinion PG over-emphasised the role of lisp in that essay. He conflated the ability to use such a language, ie that he and his colleagues are smart guys, with the language itself. They likely would still have succeeded with perl, TCL, even python was around then. And by doing so, he taught the wrong lesson.
Anyway, I think we agree more than not. And "du jour" actually means "of the day" - not necessarily age. Your point is taken, though.
Btw when we talk about Erlang, to me, is not just a matter of the language itself. How accessible, small, easy to run, the runtime of a language appears to be make for a big difference as well.
Not there are lots of reasons for choosing a platform, but if we are talking about performance:
A well written Go app tends to perform better as well: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...
Here it is with Java added back in too: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7... . What is interesting here is any node entry only comes it at better than 10th place in one benchmark.
Most people's slow Java applications are slow due to architecture/ecosystem, Java itself is pretty fast. That being said, I still prefer Go due to its elegant simplicity, easy concurrency, lack of runtime dependencies and better memory usage. Go's selective choice of which OO features to support also helps discourage some of the Java architectural bloat.
Ruby on Rails does not really have a good concurrency story for something like web sockets.
Although Rails is still what I would use for bootstrapping something where you're trying to find product/market fit and you are not absolutely sure that you need to squeeze out lots of performance from the get-go. Even if I knew I needed web sockets, I'd probably farm those out to a specific server to handle just those, most likely in Erlang.