I'd avoid the cluster module, its not the recommended way to scale Node.js. It exists mostly as a way to make naive Node.js benchmarks perform better in multi-CPU comparison testing... like yours! :-) Many cloud providers charge per-CPU, so node's "mostly not threaded approach" is reasonable, IMO and that of many other users. Node is scaled by spinning up more instances, each instance being one of the cheapest "one CPU" variety. I'd be more interested in seeing a version of your benchmark that limited each of the language instances to a single CPU, and/or that spun up multiple node instances equivalent to one multi-cpu instance of go/elixir --- this latter may sound weird, but its a "cost equivalent" comparison, which is ultimately what's important: transactions served per $$.
One of the benchmark goals was to test "scheduling" efficiency of each runtime. In other words to show how well it scales given many-core instance, which often is more economical in transaction/$$ sense.
Question: how using cluster module is different from spinning up multiple node instances?
No one is trying to "prove" 0.12 isn't coming soon, we've put lots of work into it, and look forward to its release, and its got some great new features.
I'm not sure the tag states are always up to date, perhaps they are, but the fact remains that 0.12 has been "real soon now" for quite a while, so saying it might be a while still is a pretty safe statement.
The core team is working hard, but I think the PR queue is a good indication of how scarce a resource review time is.
