Hacker News Reader

Comment by illiarian | Hacker News Reader

> as that is a part of the core semantics for BEAM languages.

It's a part of the semantics of the runtime:

- an actor is all but guaranteed to not bring down the runtime

- an actor is all but guaranteed to never affect other actors

- runtime knows how put processes to sleep until the message they listen to arrives. This means all functions are re-entrant. Well, any process is put to sleep after a cretain number of reductions so that no process takes away time from other processes.

- runtime all but guarantees that process errors are a) isolated and b) propagated. That is when a process dies all other processes that monitor it are guaranteed to receive a notification. That's why supervision hierarchies in Erlang are possible

View on HN

> - runtime knows how put processes to sleep until the message they listen to arrives. This means all functions are re-entrant. Well, any process is put to sleep after a cretain number of reductions so that no process takes away time from other processes.

This paragraph seems confused. Re-entrancy doesn't have a lot to do with sleeping. Do you perhaps mean to say something about preemption? BEAM/ERTS is not really preemptive, a process can only be suspended at specific places, but one of those places is function calls (aka reductions) and BEAM languages don't offer looping constructs other than recursion, so it's hard to go for very long without calling a function, so it's effectively/semanticaly preemptive, unless there's naughty things in NIFs you brought, or the native code provided by ERTS.

Processes being descheduled after a while doesn't mean they didn't take away time from other processes: if you have one cpu and one process running an infinite loop, adding a second one takes cpu time away from the first, but they both will get some time (if they're both set to the same priority)

> It's a part of the semantics of the runtime:

This is implied. It would be absurd to have a different static and runtime semantics. in fact, the core goal for formal methods is a statically be able to reason about runtime dynamics.

Just like it would be absurd to build a compiler for C where "+" in fact is treated as "-", it would be absurd to build a compiler and runtime system for, eg., Elixir that is not able to execute GenServers.

> This is implied.

You'd be surprised how many people miss that runtime drives this. I've seen many discussions where people claimed "you can implement all this is a library" :)

> it would be absurd to build a compiler and runtime system for, eg., Elixir that is not able to execute GenServers.

Well, Akka did it on top of JVM: https://doc.akka.io/docs/akka/current/typed/fault-tolerance.... Can't say about its limitations though.

> You'd be surprised how many people miss that runtime drives this. I've seen many discussions where people claimed "you can implement all this is a library" :)

I undrstand, everything concurrency is definitely not easy to implement in "User land" and is something you want good primitives for – why I am also amaxed over this project as they must have embedded that functionality (the scheduler) in the executable (Which they also say they did).

> Well, Akka did it on top of JVM ...

> Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala.

Akka does not seem to claim that they build a new runtime for BEAM languages?

I would argue it’s intrinsic to the language itself. In fact I did as a pedagogical tactic.

https://youtu.be/E18shi1qIHU

You can't have those things without runtime support. E.g. in Go/Rust a panic will kill the app. In Erlang an equivalent catastorphic failure in a process will kill the process, will notify the monitoring processes, the app will keep on running.

Reply on news.ycombinator.com