5 ms·

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 t

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 2y ago
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/ https://www.rebar3.org/ [2]: https://whatsapp.github.io/erlang-language-platform/ https://whatsapp.github.io/erlang-language-platform/
- _mlbt 2y ago
  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 https://github.com/dlachausse/erlmacs
  - hazbo 2y ago
    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 2y ago
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 2y ago
  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.
  - macintux 2y ago
    > 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.
    - deleted 2y ago
      [deleted]
    - freedomben 2y ago
      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 https://github.com/rusterlium/rustler

hazbo 2y ago

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/ https://www.rebar3.org/ [2]: https://whatsapp.github.io/erlang-language-platform/ https://whatsapp.github.io/erlang-language-platform/

_mlbt 2y ago
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 https://github.com/dlachausse/erlmacs
- hazbo 2y ago
  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 2y ago

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 2y ago
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.
- macintux 2y ago
  > 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.
  - deleted 2y ago
    [deleted]
  - freedomben 2y ago
    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 https://github.com/rusterlium/rustler