5 ms·

> But in 2021, you can do not just "better" than Erlang for all of them, you can do much better. Really appreciate the effort that you've put into this post bu

> But in 2021, you can do not just "better" than Erlang for all of them, you can do much better. Really appreciate the effort that you've put into this post but it's 99% saying you can do better but without examples of stacks that would be better. For those who don't have your knowledge could you provide some examples?

jerf 5y ago
The core insight of Erlang is that having lots of little processes communicating over a message bus is a great way to design code. It also proves by demonstration a statement that many programmers, especially in the past decades, would have found hard to believe, that you can structure code as a whole bunch of relatively small self-contained services. Many programmers, perhaps even today, would not believe how far you can get with such a model, thinking that fairly massive monoliths are still really the only way to scale up. Rather than specific examples, let me provide terms to google, as these are now such rich spaces that even a list of examples would be impoverish. Google "message bus"; there's half-a-dozen solid production options you can deploy yourself, and all the major clouds have at least one option, often more. Pervasively use a message bus in your architecture and you can't hardly help but end up programming in a very Erlang-esque fashion. "Database"; no longer is an SQL database over a socket your only option. Some databases even combine a bit of message bus functionality, like Redis, or Postgres. Restarting and reliability: Process-level restarting of much smaller processes has become popular with things like Kubernetes, Docker, and even just plain ol' Systemd. (This is one place that I will assert that systemd is better than the init.d-based system, which had a solid story on how to start processes but a very ad-hoc one on restarting failed processes.) Internally, consult your favorite language for monitors or restarts within a process; I've got one for Go called suture. Getting an idiomatic restart into a language depends on tons of details and I don't have a good sense of the options across dozens of languages. Note this only really matters if your language and program is handling a lot of things at once in a single process, which is not always the case. That's most of what would matter, I think. Most of the rest of Erlang like "pattern matching", well, do whatever they do in your language. Which may be pattern matching.
- nahuel0x 5y ago
  But Erlang provides something that Kubernetes/Docker/Systemd isolation does not: fine granularity / per request isolated processes. Is the difference between a code bug killing a single call in a VoIP system vs killing an entire OS process with hundreds of them.
  - shdh 5y ago
    Do you mean actors? I kinda hate how they’re always referred to as processes. https://github.com/actix/actix https://github.com/actix/actix https://github.com/akka/akka https://github.com/akka/akka
    - ramchip 5y ago
      The actor terminology isn't used in any official sources since Erlang processes are not quite "actors" in the actor model sense. They were inspired by OS processes. http://erlang.org/pipermail/erlang-questions/2014-June/079792.html http://erlang.org/pipermail/erlang-questions/2014-June/07979...
- klelatti 5y ago
  Thanks - that's very helpful.
- rhizome31 5y ago
  Sure, you can achieve what Elixir does by combining a bunch of different components replicating its features, all with their different execution schemes, configuration syntax, deployment constraints. That's the whole point of Elixir, it gives you an integrated environment to do these things with consistent vocabulary, documentation and deployment strategies.
- louissm_it 5y ago
  This comment sold Elixir for me more than anything. On a small team, each of those are massive headaches. Using Elixir I can have all of that with a unified vocabulary, documentation, deployment, syntax, repository, etc. Sure, each might be slightly worse that the best thing on offer today, but I don’t have to glue them together.

jerf 5y ago

The core insight of Erlang is that having lots of little processes communicating over a message bus is a great way to design code. It also proves by demonstration a statement that many programmers, especially in the past decades, would have found hard to believe, that you can structure code as a whole bunch of relatively small self-contained services. Many programmers, perhaps even today, would not believe how far you can get with such a model, thinking that fairly massive monoliths are still really the only way to scale up. Rather than specific examples, let me provide terms to google, as these are now such rich spaces that even a list of examples would be impoverish. Google "message bus"; there's half-a-dozen solid production options you can deploy yourself, and all the major clouds have at least one option, often more. Pervasively use a message bus in your architecture and you can't hardly help but end up programming in a very Erlang-esque fashion. "Database"; no longer is an SQL database over a socket your only option. Some databases even combine a bit of message bus functionality, like Redis, or Postgres. Restarting and reliability: Process-level restarting of much smaller processes has become popular with things like Kubernetes, Docker, and even just plain ol' Systemd. (This is one place that I will assert that systemd is better than the init.d-based system, which had a solid story on how to start processes but a very ad-hoc one on restarting failed processes.) Internally, consult your favorite language for monitors or restarts within a process; I've got one for Go called suture. Getting an idiomatic restart into a language depends on tons of details and I don't have a good sense of the options across dozens of languages. Note this only really matters if your language and program is handling a lot of things at once in a single process, which is not always the case. That's most of what would matter, I think. Most of the rest of Erlang like "pattern matching", well, do whatever they do in your language. Which may be pattern matching.

nahuel0x 5y ago
But Erlang provides something that Kubernetes/Docker/Systemd isolation does not: fine granularity / per request isolated processes. Is the difference between a code bug killing a single call in a VoIP system vs killing an entire OS process with hundreds of them.
- shdh 5y ago
  Do you mean actors? I kinda hate how they’re always referred to as processes. https://github.com/actix/actix https://github.com/actix/actix https://github.com/akka/akka https://github.com/akka/akka
  - ramchip 5y ago
    The actor terminology isn't used in any official sources since Erlang processes are not quite "actors" in the actor model sense. They were inspired by OS processes. http://erlang.org/pipermail/erlang-questions/2014-June/079792.html http://erlang.org/pipermail/erlang-questions/2014-June/07979...
klelatti 5y ago
Thanks - that's very helpful.
rhizome31 5y ago
Sure, you can achieve what Elixir does by combining a bunch of different components replicating its features, all with their different execution schemes, configuration syntax, deployment constraints. That's the whole point of Elixir, it gives you an integrated environment to do these things with consistent vocabulary, documentation and deployment strategies.
louissm_it 5y ago
This comment sold Elixir for me more than anything. On a small team, each of those are massive headaches. Using Elixir I can have all of that with a unified vocabulary, documentation, deployment, syntax, repository, etc. Sure, each might be slightly worse that the best thing on offer today, but I don’t have to glue them together.