6 ms·

If you are familiar with Go, it's similar to a goroutine that waits for someone to send it an anonymous function to start executing. In Erlang, you solve proble

If you are familiar with Go, it's similar to a goroutine that waits for someone to send it an anonymous function to start executing. In Erlang, you solve problems by spawning lots of processes, and most processes are waiting to accept messages. One critical difference is that in Erlang, processes can run on remote machines, seamlessly. This process accepts a message which is a tuple containing the atom become, which is basically just an enum, and a function. Another process, such as the Erlang shell, can send this tuple message with the function to this process at any time so that it "becomes" that function. What he is saying is that you can swap out the logic of this waiting loop with whatever protocol logic you want. His example was that he had a fleet of machines that were running this loop, and he sent all of them a function that implemented a gossip protocol. But he could easily send them all another message that turns them all into BitTorrent clients. Joe was an absolute genius and an extremely kind person. I had the honor of meeting him once. Erlang is still one of the most beautiful technical creations I've ever encountered. It really does make you see concurrency in a whole new way.

thakoppno 3y ago
> One critical difference is that in Erlang, processes can run on remote machines, seamlessly. Is there a concise way to explain how Erlang achieves this property?
- deleted 3y ago
  [deleted]
- querulous 3y ago
  it's not as mysterious as it sounds. every data structure (including modules and anonymous functions) has a binary serialization and every erlang vm is also an rpc server that can receive arbitrary data -- including whole programs -- and execute them. your vm of course needs to know about the remote vms to do so but that's where the rudimentary clustering mechanism in erlang comes into play
  - thomasfortes 3y ago
    Also no shared memory in processes and they all communicate strictly through message passing, so running a piece of code in the local node, in another node in the same machine or in a node on the other side of the planet is a matter of telling which pid you want to send the message to, the BEAM will figure out how to send the message to the correct place in the cluster and your program will be none the wiser.
- rramadass 3y ago
  You can find all the details about Erlang internals in The BEAM book : https://blog.stenmans.org/theBeamBook/ https://blog.stenmans.org/theBeamBook/
- coldtea 3y ago
  It's basically a distributed RPC system. Your call is a message.
tombert 3y ago
> Joe was an absolute genius and an extremely kind person. I had the honor of meeting him once. Completely agree. Joe was always willing to reply to my emails and answer my questions in detail. He was an exceptionally talented explainer, and his messages were always interesting and entertaining, while also being informative. I never met him in person but I will always treasure the correspondence I had with him.
henrik_w 3y ago
On the subject of beauty, I really like this quote from Joe Armstrong: “Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!”
nojs 3y ago
I would be interested if you could elaborate on the advantages and disadvantages of Erlang/Elixir over Go. I have often heard Elixir processes likened to goroutines. Since the process model seems like the primary advantage of Erlang, why would one prefer Erlang/Elixir over Go?
- coldtea 3y ago
  More dynamic, better management, dead easy to get distributed programs in multiple machines.
- ramchip 3y ago
  The critical difference is that processes are isolated, they don't share resources like goroutines do. This makes it possible to separate the error handling from the business logic. When you open a file, a socket, allocate memory, borrow a database connection from a pool, etc. you don't need to write try/catch/finally, or defer() statements, or logging, or any kind of error handling like that - if your code crashes, the VM will take care of the cleanup (because it knows what resources are owned by your process) and the supervisor above your process will log the problem and restart the process if necessary. This makes Erlang applications much safer by default, and the business logic is clearer and simpler because it's not mixed with error recovery code (the "if err != nil" every other line that Go is famous for). The error kernel (the part of the app that must be carefully written to ensure reliability) can be kept really small[1]. This comes at a cost in performance, because data must generally be copied between processes, whereas goroutines can send pointers directly to each other. But if you can afford it, it's _very_ nice. Besides the error handling this also enables crazy observability (you can connect to a running app and inspect processes[2], kill them, send them messages, jump between nodes in a cluster, etc.), live code reload, and a bunch of nice things like that. [Process isolation also enables clustering, where processes running on different machines can talk to each other as if they were in the same OS process. The copying means it doesn't matter if the other process is remote or local.] [1] https://medium.com/@jlouis666/error-kernels-9ad991200abd https://medium.com/@jlouis666/error-kernels-9ad991200abd [2] https://github.com/zhongwencool/observer_cli#demo https://github.com/zhongwencool/observer_cli#demo

thakoppno 3y ago

> One critical difference is that in Erlang, processes can run on remote machines, seamlessly. Is there a concise way to explain how Erlang achieves this property?

deleted 3y ago
[deleted]
querulous 3y ago
it's not as mysterious as it sounds. every data structure (including modules and anonymous functions) has a binary serialization and every erlang vm is also an rpc server that can receive arbitrary data -- including whole programs -- and execute them. your vm of course needs to know about the remote vms to do so but that's where the rudimentary clustering mechanism in erlang comes into play
- thomasfortes 3y ago
  Also no shared memory in processes and they all communicate strictly through message passing, so running a piece of code in the local node, in another node in the same machine or in a node on the other side of the planet is a matter of telling which pid you want to send the message to, the BEAM will figure out how to send the message to the correct place in the cluster and your program will be none the wiser.
rramadass 3y ago
You can find all the details about Erlang internals in The BEAM book : https://blog.stenmans.org/theBeamBook/ https://blog.stenmans.org/theBeamBook/
coldtea 3y ago
It's basically a distributed RPC system. Your call is a message.

tombert 3y ago

> Joe was an absolute genius and an extremely kind person. I had the honor of meeting him once. Completely agree. Joe was always willing to reply to my emails and answer my questions in detail. He was an exceptionally talented explainer, and his messages were always interesting and entertaining, while also being informative. I never met him in person but I will always treasure the correspondence I had with him.

henrik_w 3y ago

On the subject of beauty, I really like this quote from Joe Armstrong: “Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!”

nojs 3y ago

I would be interested if you could elaborate on the advantages and disadvantages of Erlang/Elixir over Go. I have often heard Elixir processes likened to goroutines. Since the process model seems like the primary advantage of Erlang, why would one prefer Erlang/Elixir over Go?

coldtea 3y ago
More dynamic, better management, dead easy to get distributed programs in multiple machines.
ramchip 3y ago
The critical difference is that processes are isolated, they don't share resources like goroutines do. This makes it possible to separate the error handling from the business logic. When you open a file, a socket, allocate memory, borrow a database connection from a pool, etc. you don't need to write try/catch/finally, or defer() statements, or logging, or any kind of error handling like that - if your code crashes, the VM will take care of the cleanup (because it knows what resources are owned by your process) and the supervisor above your process will log the problem and restart the process if necessary. This makes Erlang applications much safer by default, and the business logic is clearer and simpler because it's not mixed with error recovery code (the "if err != nil" every other line that Go is famous for). The error kernel (the part of the app that must be carefully written to ensure reliability) can be kept really small[1]. This comes at a cost in performance, because data must generally be copied between processes, whereas goroutines can send pointers directly to each other. But if you can afford it, it's _very_ nice. Besides the error handling this also enables crazy observability (you can connect to a running app and inspect processes[2], kill them, send them messages, jump between nodes in a cluster, etc.), live code reload, and a bunch of nice things like that. [Process isolation also enables clustering, where processes running on different machines can talk to each other as if they were in the same OS process. The copying means it doesn't matter if the other process is remote or local.] [1] https://medium.com/@jlouis666/error-kernels-9ad991200abd https://medium.com/@jlouis666/error-kernels-9ad991200abd [2] https://github.com/zhongwencool/observer_cli#demo https://github.com/zhongwencool/observer_cli#demo