Erlang is built first for fault tolerance, not speed. The decisions that went into that make it also really, really good for concurrency and distribution (and so that's what it often gets touted for).
The decisions that went into C++ were for speed, and compatibility with C (and all that entails).
If you've got something truly resource intensive, yeah, you're going to need a lower level language. That's largely unavoidable. Erlang.org flat out states don't use it for number crunching.
I'd guess that 90% of what is programmed in the wild isn't that resource intensive. And given that, I'd go so far to say that most of what I've coded in Erlang is more performant than what I've coded in Java (haven't done enough C/C++ professionally to have useful data points). Why? Because the abstractions and conventions lead me to writing better code; the tooling lets me profile and find bottlenecks more easily, and even code I tweak for performance is oftentimes cleaner than it started, rather than more arcane.
Joe Armstrong, the founder of Erlang, is quoted in OTP in Action as (paraphrasing as I don't have it on hand) - "First, make it correct. Then, make it beautiful. Then, if you need to, make it performant. Chances are once you've made it beautiful you'll find it sufficiently performant". And that's been my experience with Erlang.
Nothing wrong with it just an observation. Say they shed their runtime system. libgreen got moved to a separate package. Instead of relying and encouraging creating mutliple tasks and have them fail!( well panic!) now they are moving to have error traits as return values.
Again nothing wrong with it. I think it is a good move. Just observing how it started off at one side and moved towards the other.
I think it calls for a Rust-Erlang interop.library just like there is a Java one. I would like to be able to have a Rust node. Or say create NIFs in Rust perhaps.
Well, if I need all of these options, then Erlang is obviously not the way to go. In that case, Erlang might work as a prototyping language.
My impression is, from what I've read here, that Erlang might be the preferred tool for situations in which latency is not of paramount importance. For example, when sending text-messages over the internet, it doesn't hurt if the message takes 1 or 2 seconds longer to reach its destination. However, for a webserver, every second it takes longer to load a webpage means that you lose customers.
Do you think that's a fair characterization?
In fact, since you started with benchmarks, let's return to benchmarks (I find them to generally be useless, but you're looking at them, so why not) - http://www.techempower.com/benchmarks/
Compare CPPSP (the fastest! C++!) with cowboy (a popular web framework in Erlang). They're being run on the same hardware (so we're not talking about ability to scale across nodes even), serializing JSON.
Cowboy is about 1/4th the throughput (requests per second). Now let's look at latency. Cowboy took about 4 times the time, .8 ms on average per request to the CPPSP's .2. Great, C++ all the way, right? Err...no. Look at the max and standard deviations.
Cowboy had a max latency of 3.7 ms. CPPSP had a max of 134.6. Standard deviation of cowboy was .3 ms. Standard deviation of CPPSP was .5 ms.
So Cowboy is still really quite fast, more predictable, and has far smaller outliers. What are people going to be more likely to object to, waiting 3.7 ms, or 134 ms?
Couple that with the reliability Erlang provides, the ability to scale straight outta the box (so if you find you're hitting a throughput issue you have a clear path forward), and the joy of functional coding...and it's pretty compelling, to me at least.
This, times a million. 99th percentiles and standard deviation are what truly matters in benchmarks. To liken benchmarks to automobiles, requests/second is horse power and 99th percentile/standard deviation are torque.
If you can write reasonably idiomatic Erlang from the get-go (design things in terms of gen_servers and such, instead of single-process monoliths), Erlang is a great prototyping language, because anywhere you send a message and receive something back is a point where you can drop in some other implementation of that particular bit without affecting the system as a whole.
You'll find in practice that the only time you'll be tempted to do that is if something is computationally expensive. Erlang is pretty darned good at reading from and writing to sockets in general.
It's a fine tool for this, too.