For "straight line" single thread number-crunching, other languages will often be faster. With the new JIT, I doubt they are 10 times faster, but you're right there is a difference.

That's often not the limiting factor though. Elixir makes it very easy to have excellent parallelism on your work so you actually take full advantage of processor. The design of the BEAM means that things are naturally quite low latency, and often you lose performance due to just waiting for things (this characteristic is why webservers on the BEAM are pretty fast).

The other key aspect is NX - like ML libraries in Python, Elixir is just orchestrating and the number crunching is done in C libraries or on GPU etc.

I don’t know enough about news aggregators to evaluate the claim, but presumably that is why parent mentioned both complexity and compute, not just performance.

If you need per-core number crunching performance you'd reach for Nx, similar to how you would do the crunching in Python. With OTP it's then (almost) trivially concurrent.

Compared to squeezing performance out of multiple cores with the JVM it's absurdly convenient and consumes way less RAM. I have two reasons for still working with the JVM, multiplatform desktop GUI and high quality PDF libraries that support rather low-level aspects of the standard that I need. It's kind of obvious why these things aren't readily available on the BEAM, though.

Which parts of his application need a 10x speed improvement?

performance has many dimensions. for example the cost/speed of spawning a process/thread and their intra process communication.