[29athrowaway]

I did not like Erlang.

The actor model is a good idea, functional programming is a good idea... but the Erlang tooling experience is awful and many essential tools are dated. Hiring for an Erlang team is hard. Erlang projects can be an actor spaghetti.

And many people in the Erlang community really have to check their ego. If you want to assert that Erlang is the best language, trying other languages first is a good starting point.

[hazbo]

In recent years there has been some improvement with the available tooling with the likes of rebar3[1] and just a few months ago WhatsApp released ELP (Erlang Language Platform)[2] which integrates with your IDE as a language server that provides really nice support when working with Erlang.

[1]: https://www.rebar3.org/

[2]: https://whatsapp.github.io/erlang-language-platform/

[_mlbt]

I did not know about ELP! That’s great.

If you know Emacs, there’s a really good editor mode that’s included with Erlang. Shameless plug…I made a simple tool to make it easier to configure it…

https://github.com/dlachausse/erlmacs

[hazbo]

I've had such a good experience with ELP, though did have some issues getting it working correctly with my emacs setup (that's probably somehow my fault). I will say though that for VSCode, it's a case of installing the extension, zero config and it just works!

[_mlbt]

Elixir is probably a better fit for you. You still get access to the best in class BEAM ecosystem with a more approachable and modern syntax and improved tooling.

[29athrowaway]

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.

[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?

[macintux]

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

[freedomben]

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

[agos]

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