5 ms·

Article piqued my interest, but also left me scratching my head a bit - everything mentioned is kinda vague / abstract. Elixir/BEAM are "better" but better tha

Article piqued my interest, but also left me scratching my head a bit - everything mentioned is kinda vague / abstract. Elixir/BEAM are "better" but better than what? Curious the author's prior language experience. What's he developing with it exactly? Native apps? Web stuff? Or just learning / experimenting? Didn't really understand how the Elixir / BEAM approach is different from typical threads, OS processes, or async programming models - maybe asking too much from a short post :). But still would be interesting to have some specific examples of how Elixir/BEAM is better.

grugagag 6y ago
I hope this helps: https://www.skcript.com/svr/why-choose-elixir-for-software-development/ https://www.skcript.com/svr/why-choose-elixir-for-software-d...
solresol 6y ago
- Being able to deploy an update for a program while the program is running, without shutting the process down. Your code-compile-debug-fix cycle is very, very fast, so you end up very productive. - With threads, one thread can take the others down. With OS processes, it's hard to keep track of which ones are alive and available to send to. With (most) async programming models (e.g. Javascript, Tcl) you only end up utilising one CPU. With Ada-style async programming models you have to think hard about deadlocks and mutexes. The BEAM model solves all these problems.
toast0 6y ago
There's been a lot of other BEAM articles with more details. For me, there are a few key design elements that seem atypical that weave together into a very useful environment for writing software that deals with concurrency. Erlang's basic unit to handle concurrency is called a process which is more or less equivalent to a green thread; it has it's own execution state, heap and stack. Communication to other processes is via sending and receiving messages; there's no way to express shared memory in Erlang/Elixir (although under the hood there is some sharing at times). No shared memory makes process management simpler; if a process crashes or ends there's no dangling shared state for the environment to clean up (although, you can of course have stored references to the now dead process throughout your system). No shared memory, and immutable data structures make garbage collection fairly simple; a process can stop to GC itself, but that doesn't block any other processes. Message passing is asynchronous, which lets you chose at the sender if you want to send a message and wait for the response, or send it and check for the response later; processes are not able to be interrupted, except by death, so the control flow is always clear, you can check for messages wherever you want, but you do have to check. I really like the built in support for hot loading which lets you change your system as it's running; a lot of people don't like that, and we can agree to disagree. :) Anyway, all this combines to a system where the natural way to write a concurrent system is to have one process per session, and write the process to just listen for messages either from the client or from the rest of the system and process them in a straight forward way. And if you've got millions of connections, you can have millions of processes. Each process tends to be small and easy to understand, but sometimes the interaction between the processes can get a bit tricky to understand, because it just kind of arises out of the message passing.
siscia 6y ago
The BEAM is not better. It is DIFFERENT. You can read as much as you want about the topic, but my suggestion would be to go and create something with it. You need to feel the difference yourself. If you got the time, I really suggest to try the BEAM, you will have fun and you will approach software differently (and this time also better) after you internalise the BEAM way.
- busterarm 6y ago
  There's one respect where I would say it is just _better_, in that if you want your processes to be message-passing actors, you don't have a lot of great options coming from other languages whereas in Erlang that's a fundamental design choice. "Better" is a matter of what types of systems you're trying to build.
  - m12k 6y ago
    Off the top of my head, Go and goroutines are built around message-passing as well. And Scala/Java with Akka seems pretty well-established at this point too - although it'll likely never have as broad support as something built into the language like Elixir and Go has.
    - dnautics 6y ago
      None of those other systems have solid failure-domain oriented programming baked in. Let's say there's a netsplit and you want your connection to bring down two other processes that depend on it, self-heal when the netsplit is resolved, and not have any other resources associated with the process leak (memory, file descriptors, resource pools, database connections, etc). This is like maybe two lines of elixir/erlang.
      - busterarm 6y ago
        Also, error handling seems to be the worst part of working with Go by miles. I can't even imagine building such a system in the language.
conradfr 6y ago
I agree with you. Something like https://ferd.ca/the-zen-of-erlang.html https://ferd.ca/the-zen-of-erlang.html may be a more complete picture.
ggv 6y ago
Hello, OP here. Yes, I was intentionally abstract because I thought I was writing to a smaller audience of people who had spent some time with Elixir/BEAM. I never expected the attention this has received! In my 25 year career, I've been paid to work in Lotus Notes, Java, C#, Javascript, Ruby, Clojure, and now Elixir. My employer's system is basically an integration platform. We perform background tasks on behalf of our customers that access 3rd party APIs, our database, and then decide to push some data to other systems. We do have a web interface that is mostly the status of this background processing, plus a UI for when the users need a manual action. There's other great replies touching on your technical questions, but here's my brief angle on it. BEAM processes are as isolated as OS processes, but they are very quick to spawn and need very little memory. A typical developer-caliber laptop computer can probably support on the order of a quarter million processes. Their isolated nature is supported at all levels of the design of the BEAM.
- QuadrupleA 6y ago
  Thanks - appreciate the reply (and the other helpful replies here too). I've done a fair bit of threaded / async stuff in Python / C / JS - sounds like BEAM processes are more baked into the language & runtime and encouraged as an architectural style, rather than an added complexity you bargain with when you hit a single-threaded performance wall. Interested to do a deeper dive on it sometime.

grugagag 6y ago

I hope this helps: https://www.skcript.com/svr/why-choose-elixir-for-software-development/ https://www.skcript.com/svr/why-choose-elixir-for-software-d...

solresol 6y ago

- Being able to deploy an update for a program while the program is running, without shutting the process down. Your code-compile-debug-fix cycle is very, very fast, so you end up very productive. - With threads, one thread can take the others down. With OS processes, it's hard to keep track of which ones are alive and available to send to. With (most) async programming models (e.g. Javascript, Tcl) you only end up utilising one CPU. With Ada-style async programming models you have to think hard about deadlocks and mutexes. The BEAM model solves all these problems.

toast0 6y ago

There's been a lot of other BEAM articles with more details. For me, there are a few key design elements that seem atypical that weave together into a very useful environment for writing software that deals with concurrency. Erlang's basic unit to handle concurrency is called a process which is more or less equivalent to a green thread; it has it's own execution state, heap and stack. Communication to other processes is via sending and receiving messages; there's no way to express shared memory in Erlang/Elixir (although under the hood there is some sharing at times). No shared memory makes process management simpler; if a process crashes or ends there's no dangling shared state for the environment to clean up (although, you can of course have stored references to the now dead process throughout your system). No shared memory, and immutable data structures make garbage collection fairly simple; a process can stop to GC itself, but that doesn't block any other processes. Message passing is asynchronous, which lets you chose at the sender if you want to send a message and wait for the response, or send it and check for the response later; processes are not able to be interrupted, except by death, so the control flow is always clear, you can check for messages wherever you want, but you do have to check. I really like the built in support for hot loading which lets you change your system as it's running; a lot of people don't like that, and we can agree to disagree. :) Anyway, all this combines to a system where the natural way to write a concurrent system is to have one process per session, and write the process to just listen for messages either from the client or from the rest of the system and process them in a straight forward way. And if you've got millions of connections, you can have millions of processes. Each process tends to be small and easy to understand, but sometimes the interaction between the processes can get a bit tricky to understand, because it just kind of arises out of the message passing.

siscia 6y ago

The BEAM is not better. It is DIFFERENT. You can read as much as you want about the topic, but my suggestion would be to go and create something with it. You need to feel the difference yourself. If you got the time, I really suggest to try the BEAM, you will have fun and you will approach software differently (and this time also better) after you internalise the BEAM way.

busterarm 6y ago
There's one respect where I would say it is just _better_, in that if you want your processes to be message-passing actors, you don't have a lot of great options coming from other languages whereas in Erlang that's a fundamental design choice. "Better" is a matter of what types of systems you're trying to build.
- m12k 6y ago
  Off the top of my head, Go and goroutines are built around message-passing as well. And Scala/Java with Akka seems pretty well-established at this point too - although it'll likely never have as broad support as something built into the language like Elixir and Go has.
  - dnautics 6y ago
    None of those other systems have solid failure-domain oriented programming baked in. Let's say there's a netsplit and you want your connection to bring down two other processes that depend on it, self-heal when the netsplit is resolved, and not have any other resources associated with the process leak (memory, file descriptors, resource pools, database connections, etc). This is like maybe two lines of elixir/erlang.
    - busterarm 6y ago
      Also, error handling seems to be the worst part of working with Go by miles. I can't even imagine building such a system in the language.

conradfr 6y ago

I agree with you. Something like https://ferd.ca/the-zen-of-erlang.html https://ferd.ca/the-zen-of-erlang.html may be a more complete picture.

ggv 6y ago

Hello, OP here. Yes, I was intentionally abstract because I thought I was writing to a smaller audience of people who had spent some time with Elixir/BEAM. I never expected the attention this has received! In my 25 year career, I've been paid to work in Lotus Notes, Java, C#, Javascript, Ruby, Clojure, and now Elixir. My employer's system is basically an integration platform. We perform background tasks on behalf of our customers that access 3rd party APIs, our database, and then decide to push some data to other systems. We do have a web interface that is mostly the status of this background processing, plus a UI for when the users need a manual action. There's other great replies touching on your technical questions, but here's my brief angle on it. BEAM processes are as isolated as OS processes, but they are very quick to spawn and need very little memory. A typical developer-caliber laptop computer can probably support on the order of a quarter million processes. Their isolated nature is supported at all levels of the design of the BEAM.

QuadrupleA 6y ago
Thanks - appreciate the reply (and the other helpful replies here too). I've done a fair bit of threaded / async stuff in Python / C / JS - sounds like BEAM processes are more baked into the language & runtime and encouraged as an architectural style, rather than an added complexity you bargain with when you hit a single-threaded performance wall. Interested to do a deeper dive on it sometime.