Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The "best in class" you refer is behind the reality of most tech stacks 10 years ago.

Yes, the concurrency is great, but it is concurrency you would probably not need if the code executed faster in the first place. 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, does what's supposed to do without the spaghetti actor mess and with a sane compiler that actually does work for me instead of the other way around.

The ecosystem is full of circular statements like "[Erlang|Elixir] is the best because [Erlang|Elixir] is the best". Maybe in the 90s the only realistic way to achieve concurrency without going insane was Erlang, I give you that. But it's 2024 and it's a different world now and the successful ideas in Erlang have influenced other tech stacks to some degree. Yes, Erlang is still unique in useful ways but the cost is using tooling from the paleolithic.

Let's use some common sense to try to find out if this is really true: If it is so great then why is it that almost nobody uses it? Who is claiming it is the best? The very few people that use it, who in their majority refuse to use anything else. That makes it look like a sad echo chamber at times.

I wish everyone over there the best but trying to make friends by claiming everyone else has no idea about what they're doing for years is not effective. Your company is not WhatsApp or a telecom company and most likely you don't need Erlang. If you have the specific problem where Erlang shines, by all means use it, but that's space is very narrow.



> 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.


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


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


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?


> Yes, the concurrency is great, but it is concurrency you would probably not need if the code executed faster in the first place.

If you're using Erlang concurrency for performance you're probably doing it wrong.


Well, it depends on the bottleneck. CPU-bound code, I would of course agree. For I/O bound though, especially network I/o with variable peers (which is the vast majority of code written nowadays) erlang's concurrency model is fantastic.

Also worth mentioning is that you can write CPU intensive code in rust and invoke it as NIFs[1]

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


it's not only telcos which have concurrency problems. you'll find they are quite frequent in programming




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: