
Joe Armstrong on Elixir (2018) - tosh
https://elixirforum.com/t/learning-elixir-frst-impressions-plz-dont-kill-me/16424/52
======
bsaul
Wonder why after all this time nobody managed to replicate erlang concurrency
mechanism successfully. I’ve heard about actors framework in other
environments ( such as akka in .net and java), but i feel that the approach
that really became mainstream is node style single thread with callbacks and
async / await mechanism.

Especially, erlang seems like the only environment where the concurrency model
has such a big implication on how you build your whole system ( as opposed to
just letting the framework spawn actors underneath without you even noticing,
like i’ve seen in some recent dart web framework)

For example in swift, chris lattner set actor as a long term goal for
concurrency, but async seems to be going to be implemented first ( probably
for very good practical reasons). Yet the way erlang does it seems to be so
core to its design that i’m very skeptical we’ll reach something similar.

~~~
rdtsc
Because fault tolerance and isolation has to come with it.

It actually has been replicated successfully in modern multiuser operating
systems. You can safely restart your web server process while the cron service
or your DB stays up. One user's shell crash doesn't take down all the other
ones.

The power of BEAM VM is making it possible to start millions of such processes
on a machine.

There have been many instances of anyone starting a bunch of threads with some
message queues and calling it "a modern super-fast Erlang" but it's just
solving the wrong problem.

~~~
bsaul
To me something really important is also transparent cross-machine
communications. The fact that you don't really care where an actor is running
on your network (local or remote) as you long you've got its ID is the most
seducing aspect of the whole environment.

------
sergiotapia
Joe helped me a lot of times on the elixirforum and it was really eye opening
how his solutions were so radically different than most.

He wrote really functional elixir, and you could tell he commanded expertise
rarely seen. To have such a senior engineer spend his time teaching beginners,
it was really inspiring. He'll be sorely missed by everybody in the Elixir
community.

------
ssivark
Could someone elaborate (or link to a reference) on Joe's point about how
having many processes can help build fault tolerant systems? I know next to
nothing about Erlang/Elixir or the actor model, but I'm curious about the
underlying principles. My primary interest for now is not necessarily in
scalability, but actually in engineering fault-tolerant systems.

EDIT: To give some more context... I'm thinking about software systems that
must interact with the real world (eg: robotics) where it is very hard to give
guarantees that a certain action would necessarily have the desired effect.
Also, it is very common for agents to function with an incomplete model of the
world (which essentially encodes their assumptions on how the world ought to
respond to their actions) and keep adapting their responses and changing their
model based on observations. (BTW, thinking along these lines lead to an
approach called behavior-based robotics)

~~~
di4na
Joe Thesis is probably the best place to begin with.

[http://erlang.org/download/armstrong_thesis_2003.pdf](http://erlang.org/download/armstrong_thesis_2003.pdf)

~~~
ssivark
Thanks for the link; will read.

------
PopeDotNinja
> Objects are things that respond to messages (or should be) - to get an
> object to do something you send it a message - how it does it is totally
> irrelevant - think of objects as black boxes, to get them to do something
> you send them a message, they reply by sending a message back.

The part I love about Elixir is the "objects" don't have to send a message
back! There's no need for the sender to sit around waiting for a reply.

------
itsthecourier
RIP Joe

