4 ms·

>Scala/Akka would be another choice but it has totally different semantics from Erlang, and you can never forget you are working in an async model The actor mo

by tormeh 10y ago

>Scala/Akka would be another choice but it has totally different semantics from Erlang, and you can never forget you are working in an async model The actor model is asynchronous by definition. Did you maybe intend to say something else? What makes Erlang different is that the BEAM VM is made for the actor model, so it has per-actor GC and other things that are basically impossible in other languages that don't use BEAM.

phamilton 10y ago
I think if you replaced "an async model" with "a shared event loop" I agree with the expressed frustration.
jeremyjh 10y ago
Erlang and Haskell give you a sequential programming model for I/O (and everything else) within each actor process. You can read from a file, take a result from it, do a database query then post a message to another process. In Akka, you must use asynchronous I/O directly, or use a thin abstraction such as Futures with monadic bind to accomplish the same thing. Under the covers, the Haskell and Erlang runtimes are handling this for you so that you can forget about the fact that you are doing async I/O. In Akka, if you don't pay attention to this and use a non-NIO Java library to do I/O, you will block the entire scheduler. Whereas, every library in the Erlang and Haskell ecosystems already uses the async I/O abstractions in the runtime.
Matthias247 10y ago
> The actor model is asynchronous by definition For sure the independent execution of the actors internal logic is a fundamental property of an actor system. However I think communication APIs between actors don't have to be asynchronous by definition: In Akka they are, because blocking threads woul kill the performance. In Erlang synchronous communication between actors works fine. The C# Orleans framework also favors "synchronous" communication - yes, actor communication returns Task<T> results which can be awaited, so it's async unter the hood - but I consider that an implementation detail). Pony in contrast leans to purely async APIs. There's no way to actively wait for a response from another actor. The advantage is that deadlocks are not possible at all, whereas with synchronous actor communication you can deadlock when 2 actors are waiting upon each other. The drawback are callbacks and the need to model everything as a state machine.
- klibertp 10y ago
  > In Erlang synchronous communication between actors works fine. There is no such thing as synchronous communication in Erlang! When coding in Erlang you better remember this. The primitive operation in Erlang is the async message send and that's it. Sync messages are built on top of async send, blocking receive blocks and a lot of overhead involving linking and monitoring (because the process you're sending to may die before the message arrives or before it can send the response). All this is handled by gen_somethings (`gen_server:call` does this, for example), but sync messages are not the basic primitive in Erlang. They may work, but they are not trivially implemented - I know, I tried working without OTP for a while. I reimplemented a lot of edge-cases handling in my project back then and when I finally checked library sources I was shocked to learn that it was still less than a half of what was needed...
  - Matthias247 10y ago
    I wrote synchronous communication, with which I meant the combination of a sending a request message and do a blocking wait for a response message. I'm aware that the pure message sending in Erlang is async. What I intended to highlight is that the "do a blocking wait for a response" part is possible in Erlang, but not in Pony or Akka (yes, you can do it in Akka, but it's not recommended for performance reasons).

by tormeh 10y ago

phamilton 10y ago

I think if you replaced "an async model" with "a shared event loop" I agree with the expressed frustration.

jeremyjh 10y ago

Erlang and Haskell give you a sequential programming model for I/O (and everything else) within each actor process. You can read from a file, take a result from it, do a database query then post a message to another process. In Akka, you must use asynchronous I/O directly, or use a thin abstraction such as Futures with monadic bind to accomplish the same thing. Under the covers, the Haskell and Erlang runtimes are handling this for you so that you can forget about the fact that you are doing async I/O. In Akka, if you don't pay attention to this and use a non-NIO Java library to do I/O, you will block the entire scheduler. Whereas, every library in the Erlang and Haskell ecosystems already uses the async I/O abstractions in the runtime.

Matthias247 10y ago

> The actor model is asynchronous by definition For sure the independent execution of the actors internal logic is a fundamental property of an actor system. However I think communication APIs between actors don't have to be asynchronous by definition: In Akka they are, because blocking threads woul kill the performance. In Erlang synchronous communication between actors works fine. The C# Orleans framework also favors "synchronous" communication - yes, actor communication returns Task<T> results which can be awaited, so it's async unter the hood - but I consider that an implementation detail). Pony in contrast leans to purely async APIs. There's no way to actively wait for a response from another actor. The advantage is that deadlocks are not possible at all, whereas with synchronous actor communication you can deadlock when 2 actors are waiting upon each other. The drawback are callbacks and the need to model everything as a state machine.

klibertp 10y ago
> In Erlang synchronous communication between actors works fine. There is no such thing as synchronous communication in Erlang! When coding in Erlang you better remember this. The primitive operation in Erlang is the async message send and that's it. Sync messages are built on top of async send, blocking receive blocks and a lot of overhead involving linking and monitoring (because the process you're sending to may die before the message arrives or before it can send the response). All this is handled by gen_somethings (`gen_server:call` does this, for example), but sync messages are not the basic primitive in Erlang. They may work, but they are not trivially implemented - I know, I tried working without OTP for a while. I reimplemented a lot of edge-cases handling in my project back then and when I finally checked library sources I was shocked to learn that it was still less than a half of what was needed...
- Matthias247 10y ago
  I wrote synchronous communication, with which I meant the combination of a sending a request message and do a blocking wait for a response message. I'm aware that the pure message sending in Erlang is async. What I intended to highlight is that the "do a blocking wait for a response" part is possible in Erlang, but not in Pony or Akka (yes, you can do it in Akka, but it's not recommended for performance reasons).