Joe Armstrong on Elixir (2018) | Hacker News Reader

Joe Armstrong on Elixir (2018)

elixirforum.com

140 pointstosh20 comments

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.

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.

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.

One reason Erlang can do this is by having a preemptive scheduler. [1] In a single threaded language like JavaScript, if something blocks for 1 second, nothing else happens for 1 second. In Elixir, you can have N things that each block for 1 second, and have them all still complete in one second, even if you are running on a single core.

[1] https://en.wikipedia.org/wiki/Preemption_(computing)

Not really valid. In JS if a function blocks for 1 sec, the scheduler executes another function. The whole thread blocks for 1 sec only when all its async based functions block.

The concurrency model is based on the event loop: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Even...

Not all JavaScript code is async. If you write an infinite loop what takes a while, you'll lock up your entire JavaScript thread...

let count = 0 ; while (count < 1000000000) { count += 1 }

Counting from 1 to a billion will block any other operation from happening. In Elixir, that's not the case. Or am missing something?

I also wonder why async/await became the dominant paradigm, with Python, JavaScript, and Rust borrowing it from C# as far as I can tell.

I buy the "what color is your function?" argument: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

If you look at Python, it has spawned sort of a parallel standard library / language around async/await. For example, as of Python 3.7 contextlib apparently has an AsyncContextManager ("with"). There are async versions of the "itertools" module floating around.

Although, Go is more like Erlang in that it doesn't suffer from this problem.

But Python and JS are two of the most popular languages in the world, so I guess that means async/await "won" ?

"I also wonder why async/await became the dominant paradigm"

Having only followed the discussion about concurrency on the swift language, it seems async/await is clearly more straightforward to implement starting from a regular C-stack like compiled language, than an erlang-like system with its VM looking a lot like an OS of its own.

Abour Rust, i've seen a few actor-based frameworks, and i'm really putting a lot of hope in this language, since it seems to have both the taste for high-level & hard to implement features, and the community that goes with it. Unfortunately, here too i think the core language team needs to be heavily involved for this pattern to succeed.

In the meantime, i think i've got no other choice than to start using elixir+OTP or erlang+OTP.

Maybe the Pony programming language[0] would be of interest to you? Actor-model concurrency is built into the language. I recommend reading through their book[1] in order to get a somewhat good understanding about what it brings to the table. People who like Erlang's concurrency and Rust's compile-time safety & performance will most likely find Pony interesting.

[0]: https://www.ponylang.io/discover/#what-is-pony

[1]: https://tutorial.ponylang.io/

Pony seems like a good start, but FWIU it lacks the equivalent of OTP regarding the scheduling / spawning of actors over a network of machines.

Pony's actors are also cooperatively scheduled; Erlang's "killer feature" (or one of them, at least) is the ability to have lightweight preemptive processes.

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.

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)

He wrote a whole PhD thesis about it, so that's where I'd start if you're interested in the topic.

Joe Thesis is probably the best place to begin with.

http://erlang.org/download/armstrong_thesis_2003.pdf

Thanks for the link; will read.

The key is that the memory of these processes is isolated from all the others.

Think of how operating system process work. You can restart a small group out of 1 million and have confidence the rest are not affected. That is a powerful and awesome ability.

Imagine you have a million threads all sharing the same data structures with complicated barriers, locks, mutexes, and condition variables. Some subset of them crash, can you confidently restart just those threads? Usually no, because they could have scribble on the memory that other threads will use, or might be holding some lock and such.

In operating systems terminology it's like when your calculator app crashed and it took down your word processor as well in Windows 3.1 days.

You know how you can write a daemon that starts a service, and then restarts the service if it crashes. Usually you'd use a service like that in your operating system init process: System V, Launchd, Systemd, Runit, etc. Now imagine the ability to do that in a program. You can write an elixir process, start it with a supervisor, and if the process crashes, the supervisor automatically traps the exit signal & and starts a new process. No messing around with operating system init shenanigans required!

> 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.

RIP Joe

Reply on news.ycombinator.com