How does it compare to lunatic https://github.com/lunatic-solutions/lunatic ? (besides wasm vs. native)

Also, what's the deployment story?

As far as deployment, do you mean like how we came to build this? Or like how you'd actually deploy it...? Because that's really up to the program being built imo

I mean that deployment of Erlang code on a BEAM cluster is pretty simple, iirc. I wonder if you have a solution that handles that part as conveniently as Erlang/Elixir/BEAM.

Regarding the implementation, I would have preferred to have different handler implementations for the various message types instead of a big enum. It's not rare to have 4-5 messages for a single actor and the current approach will make it messy very fast.

One big thing of actix is the ability to control the concurrency of message processing in the async case (sequential or parallel). How does Ractor does it?

1. If you would want independent message handlers, normally we'd just add functions off the state which would be called strait from the message handler's match statement. I.e. something like self.handle_msg_1(message, state, ...). We looked at having multiple handlers but you kind of either get into generic's hell or having to do some kind of ugly proc macro. We figured this left it up to the implementor on how you want to handle it

2. Sequential processing would really be a factory. That would do parallel work of jobs using a basic actor implementation while handling concurrent work limits, job routing, etc. Otherwise you could always spawn inside your actor and like a wait on multiple handles if you wanted, but that gets messy and kind of diverges from the true intent. There is a factory implementation in the base ractor lib, feel free to take a look!

I think it’s fair to say that the actor model is analogous to FP, but for distributed (and to a lesser extent multithreaded) computing. Just like FP has friction against imperative programming, there is a similar friction when interoping with traditional systems. Likewise, benefits pile up once you have some critical mass of subsystems that all use the actor model, where certain problems just go away.

I’m personally a big believer, it fits my mental model as I like to think about data flows first. That said, almost all systems today are request-response, so you have to either accept a certain amount of friction or embrace the much smaller ecosystem of message-based systems.

Just like regular programming is going more and more multi-paradigm, incorporating FP and others into mainstream langs, it seems like the distributed world is moving slowly in a multi-paradigm direction as well. For instance, databases and file systems are increasingly using message/event streams and sometimes exposing them directly to users.

https://www.amazon.com/Seven-Concurrency-Models-Weeks-Progra...

At the core, this is an actor: Just as an object fundamentally binds some bit of data to some set of methods that operate on it, an "actor" is a binding of a thread to some data, such that no other thread will ever access it. Therefore, there is no locking problem on that data and the actor has full control over it. It embeds an island of single-threaded processing in a sea of multithreading. It's a "server" with all the reductions in complexity you can apply to it for being in process rather than an external process communicated with via some stream.

As with objects, you can elaborate on that theme in a number of ways. You can enforce at the language level that actors have unique access to certain data (Erlang/Elixir, Pony). You need some communication system; you can bless one as part of the language runtime (Erlang/Elixir mailboxes, Go channels). You can build in support for various structures on top of official actors just as you can build support for various object structures once you have an official concept of an object, like supervisor trees and crash notification (Erlang/Elixir). You can provide actor-level polymorphism by defining protocols they have to conform to. You can embed actors into a structured concurrency model (no language yet [1], as far as I know!) to create a "structured actor" model.

However, just like objects, you get hordes of people insisting that their way is the one true way of doing actors and if you can't check off EVERY LAST BULLET POINT FEATURE of their preferred implementation you don't have actors. I imagine what you are picking up about actors are these people, who come away thinking that if you aren't Erlang, you aren't using actors. These people are wrong, just as people who think that if you aren't exactly Java you don't have objects. Actors at their core are very simple; really the only thing you have to have to get them right is to make sure that an actor's data is only accessed from one thread. Just as I tend to take an expansive view of "object orientation" that it is simply about having "methods" of some sort attached to data structures and I don't sit there and argue about how you need to have a "protected" key word and all the structure that implies to have an object system.

While language support for completely rigid isolation of data to a thread is nice in some ways, it is not necessary, and it can also sometimes be a problem if you want to do something else; it is not hard to accomplish the goal with other tools. For instance, in most object oriented systems you can accomplish this with a factory/constructor function that creates an object and spawns its associated thread, using some variant of "private" to make it so only that thread ever receives access to the internal data. I'd even consider that second clause optional in the case of a language like Python, where private-ness is more convention than strict enforcement. But push comes to shove, nothing stops you from writing actors in C, just as you are not stopped from writing objects in C. You just get zero language support.

In fact everything in the paragraph about what you can build on top of actors can be built as libraries. It's just that the tradeoffs vary from system to system. I implemented supervisor trees in Go, for instance. They aren't exactly what is in Erlang, but they largely solve the problems I have. A language may not have support for an "actor protocol" but using an object oriented language's concept of polymorphism allows a rough equivalent through implementing methods that encapsulate communication with the actor does roughly the same thing and solves the same problems. It isn't always perfect, but there's never a perfect solution to every problem in a given language. Having perfect actors implies some other weaknesses somewhere else.

So, yes, the concept of binding data to threads is a critical one to building modern systems. While I generally phrase the errors of the 1990s threading hell world in terms of their locks, a complementary view is to say that the screw up of our first pass at threading, with the attendant fear still echoing through our community to this day, was the attempt to allow all threads access to all data all the time. When you don't do that, you don't get the threading hell of the 90s. Actors are not the only solution to the problem, but binding data to specific threads is one of the basic tools in solving it. Extremely important to sane multithreaded programming.

[1]: Yes, this includes Erlang; in Erlang you can still "spawn" whenever you feel like it. It is true that usage of the OTP library encourages things that look like "structured concurrency" but it does not enforce it, nor does it take advantage of some of the things that structured concurrency would allow. And I'm talking about languages and their strict enforcement here, and as basic as OTP may be, it is still a library.

http://dist-prog-book.com/chapter/3/message-passing.html

I would also say that matches the academic viewpoint fairly well. It shows how my reductionistic view of actors as the important thing being the binding of data to a specific thread of execution is a fairly heterodox view. I don't want to hide that. Note how that link does discuss data, but it isn't anywhere near as front-and-center as I would put it. If I were writing a similar survey, it would probably be my organizing metaphor, rather than message passing. I'm not criticizing that organization; it's a completely valid handle on the problem as well. It's just not what I would use.

At the end, they disclaim Communicating Sequential Processes as not being an actor model. By their terminology, this is correct. By my heterodox view, though, I would still put them under the "actor" category, at least in general (I don't know if it's strictly speaking necessary for the processes to have isolated data, but even if not specified one does wonder what the point of all the communication is on a practical level if the processes can just reach in to each other's data sets), and to me they would be another example of the various elaborations you can apply to them.

Ultimately what kept me out of academia is I had too much of a hybrid engineering/academic view to fit into either one comfortably, and I could tell there wasn't much room for an "in between" all protestations to the theoretical desirability of cross-discipline cooperation notwithstanding. There's a sense in which all the details in that link matter. But there's another sense in which 75% of the problem is solved just by ensuring that you've got some data that can only be accessed by a given thread of execution, another 20% that you can't hardly help but solve beyond that (e.g., you will come up with some sort of messaging solution, and the details of that solution may affect your architecture but broadly speaking any half-sane solution will generally be able in some way to solve any problems you have somehow), and the remaining 5% is academically interesting but from an engineering perspective will generally only start to bite you at very large scales, so are only worth worrying about if you expect to scale that far. The latter point of view is... not the common approach academics take.

But you don't need to worry about a lot of that stuff to just get started. The guidelines I've given in these couple of posts will get you the vast bulk of real value with a fraction of the concepts, and while you will need to choose some sort of system to use your actors, the complexity is less than it appears because most of the time any of these solutions will work for you, or you'll be choosing them on completely other criteria like implementation language or network protocol compatibility.

... And you can't have both.

So it's a tradeoff on stuff like syntactic sugar and speed imo

> Orleans is used by Microsoft in Azure, Xbox, Skype, Halo, PlayFab, Gears of War, and many other internal services. Orleans has many features that make it easy to use for a variety of applications.

https://learn.microsoft.com/en-us/dotnet/orleans/overview

Until Ractor proves itself in similar workloads, it is a tiny bit more than syntax sugar difference.

`handle_call(pattern, from, state)`

Return your reply and your new state and boom. It just works.

What happens if the actor mutates the state then fails?

Do you just dirty the state and throw it away or do you retry at all?

It is WebAssembly based though, so it should be easier than trying to deal with dynamic libraries and Rust's ABI.

In practice, is the handle function going to match on each message and then call a handler for that specific message which may then match on the state?

At least Rust doesn't have a garbage collector, so when the actor is stopped + dropped, it'll cleanup not only it's state but also it's message queue's flushing them so that all memory is released at the time of drop.

Especially the type-safe actor abstractions saved us many bugs, e.g., sending an uint32 but trying to receive a uint64.

https://actor-framework.readthedocs.io/

One question: what happens for panics that won’t be able to be catched by std::panic::catch_unwind?

https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

Somebody else's Show HN is not really a great time or venue to tangent off into some language war.