3 ms·

I may be answering the wrong question, but I’ll give it a shot. Erlang’s architecture is unusual; both the virtual machine and the language are built around th

I may be answering the wrong question, but I’ll give it a shot. Erlang’s architecture is unusual; both the virtual machine and the language are built around the idea of tiny processes operating concurrently, each process running in an infinite loop waiting for incoming messages to interpret. This allows a process to become whatever code you send it. If you need a process to control a microwave, and then run some quantum computations, and then predict the winner of tomorrow’s football game, you just send it the code it needs for each operation and it happily does so.

notRobot 3y ago
Ah, so TL;DR is that each process evals the supplied code and returns the output to the caller?
- macintux 3y ago
  Slightly different in the low-level details, but conceptually accurate.
- Jtsummers 3y ago
  The universal server may or may not return anything. It just executes whatever is passed to it. In Erlang there are two ways of "calling" (in quotes for a reason). There's conventional function calling which is the regular synchronous style that we all know and love: f(10). This will produce a result and return it to its caller. The other isn't really a call, it's "sending": Pid ! 10. Some process id has been sent the value 10. It may be on this same node, it may be on another node, I don't have to care (sometimes I do though). This is asynchronous. Once a send is done the sending process will continue on (perhaps even terminating). At the other end of the send is a receive (hopefully, otherwise somebody's queue is getting filled up...): receive N -> ... % do something with this value end. In the case of `universal_server` we don't know what it will become, it's just going to execute whatever 0-ary function is passed. That function may or may not include a "return" (sending a value back to the origin). It could also just terminate the universal server. Or it could temporarily convert the universal server into something else and then become a universal server again.

notRobot 3y ago

Ah, so TL;DR is that each process evals the supplied code and returns the output to the caller?

macintux 3y ago
Slightly different in the low-level details, but conceptually accurate.
Jtsummers 3y ago
The universal server may or may not return anything. It just executes whatever is passed to it. In Erlang there are two ways of "calling" (in quotes for a reason). There's conventional function calling which is the regular synchronous style that we all know and love: f(10). This will produce a result and return it to its caller. The other isn't really a call, it's "sending": Pid ! 10. Some process id has been sent the value 10. It may be on this same node, it may be on another node, I don't have to care (sometimes I do though). This is asynchronous. Once a send is done the sending process will continue on (perhaps even terminating). At the other end of the send is a receive (hopefully, otherwise somebody's queue is getting filled up...): receive N -> ... % do something with this value end. In the case of `universal_server` we don't know what it will become, it's just going to execute whatever 0-ary function is passed. That function may or may not include a "return" (sending a value back to the origin). It could also just terminate the universal server. Or it could temporarily convert the universal server into something else and then become a universal server again.