[pton_xd]

> In most cases, you can do all the concurrency tricks you want but if you put the same code in Rust, it just goes brrrr

If "just go brrrr" is your idea of concurrency then I agree, Erlang is not the right tool for you.

Concurrency can also be used for fault tolerance and high-availability. Erlang is known for its "just let it crash" philosophy of developing robust distributed systems that "run forever."

Along those lines Erlang provides a whole host of useful tools right out of the box, like being able to inspect and modify! a live system without any prior planning or instrumentation.

It's really an amazing language.

[prophesi]

Yep, I think you'd be hard-pressed to find the actual Elixir code to be the bottleneck in a real-life application. But if you do encounter that, you can use something like Rustler[0] for the CPU-intensive bottleneck, as Discord did[1] while working on a data structure they needed. Slow DB queries are something else to look out for.

edit: Didn't see Rustler was already mentioned in a sibling thread, but hopefully the Discord tidbit will be interesting to others.

[0] https://github.com/rusterlium/rustler

[1] https://github.com/discord/sorted_set_nif

[29athrowaway]

And then all that is undone and ran in a processor with registers which is essentially imperative with shared mutable state again. Congrats

[hazbo]

Does this logic not basically invalidate anything that isn't imperative at a high level that eventually runs on a processor? Like, "why bother writing Haskell? It just gets compiled and ran imperatively." Isn't the whole point that you can reason about Haskell?