[Zababa]

> Unsurprisingly, Rust outperforms Elixir by 2 orders of magnitude.

That seems very surprising to me. Is this a common result? I've heard that the BEAM is not the best for "number crunching" code, is this one of those scenarios? Is this really just the raw performance of the languages, or a difference in algorithms? There's also no mention of the version of Elixir and the OTP. Did the JIT change anything?

[jerf]

Heavy duty string bashing is a pessimal case for BEAM, yes. The two core data structures you could use for this, the binaries or the 'strings' (which are linked lists of characters), each have their own problems with this sort of algorithm. Erlang was designed to fling chunks around, maybe take a header apart before deciding where to fling a chunk around, not to grovel over every byte of some fairly-large string for detailed parsing.

Based on performance numbers I've seen, I'd expect a one-order-of-magnitude difference to be a more common case in general.

[Communitivity]

For me, Elixir with Rust NIFs seems like a match made in heaven.

The BEAM VM is amazing at many things but it is still a VM and while the BeamAsm Just In Time compiler added in 2020 can offer performance improvement gains of 130%, there are areas where the BEAM still won't outperform native code.

Erlang excels at network programming and binary data processing. Computation intensive math and heavy string processing are both good NIF use cases.

An article on string performance [1],pre-JIT, describes initial Elixir benchmark of 140s vs C's 3.74s. They managed to make a number of tradeoffs and get the Elixir benchmark improved to 13s. Part of how they did that was to not use unicode (IO.binstream instead of IO.stream), that alone gained them ~4s.

[1] https://blog.jola.dev/elixir-string-processing-optimization