Hacker News Reader

Comment by bsaul | Hacker News Reader

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.

View on HN

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.

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.

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?

Reply on news.ycombinator.com