3 ms·
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 n
by 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 agoThere'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 agoOff 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 agoNone 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 agoAlso, 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.