Sorry for being so negative but why do people keep building these Actor frameworks for Rust? None of them get any usage.
[1] https://slawlor.github.io/ractor/assets/rustconf2024_present...
It's come a long way since it started and I'm thrilled I can talk about it publicly now and it's usage at Meta (some at least lol).
The actor model is imo a great way of doing concurrency in the absence of the data race guarantee that safe rust provides at compile time. If you know you have no data races, I don't think actors give you that much.
That said, some people just really like actors as a mental model and/or they want to interoperate with actor-based systems written in other languages or provide an actor substrate written in rust that will be embedded into another language perhaps? It's definitely a niche usage.
This is me, for sure. "little box does one thing, processes one thing at a time, maintains the state of one thing, talks to different pieces of the system through this predefined method", etc, that actors give me is very easy for me to reason about and work with, so I use it and love it.
There are good answers already on the actual "why", but I'd like to point out that "none of them get any usage" is a much better reason to build a new one than "there's already a library dominating the ecosystem". Clearly none of the existing libraries, for one reason or another, have been deemed interesting enough, let's see someone else try
- One decides that they want to use actors
- Look for frameworks
- find those that either abandoned or don't vibe with one
- start your own
- passion runs out for project that needed actors
At the same time Web servers seem a bit better as I don't really want to be figuring out how many actors of each "class of actor" to spawn and to maybe babysit each of them, and for debugging the web stack has more tooling and is better understood than any particular actor system. The advantages seem mostly out of experience and a lot of time. Maybe some iteration of an Actor framework will render Web servers too quirky/unsafe/slow/complex.
Homogenous tasks should use an approach that is aware of and takes advantage of the homogeneity, e.g., the sort of specific optimizations a framework might make to orchestrate data flows to keep everything busy with parallel tasks.
You can use actors for orchestration, but you're really just using them because they're there, not because they bring any special advantages to the task. Any other solution that works is fine and there would never be a particular reason to switch to actors if you already had a working alternative.
There's also the entire category of "data lakes" and other nouns that have "data" applied as an adjective that includes various orchestration techniques because just being storage isn't enough, that is its own entire market segment.
Github stats show some uptake so clearly someone finds them useful
Also, didn't what I said about usage better map to number of dependent crates or downloads by cargo? Both are listed on https://crates.io/crates/ractor
True, but find me one language that someone, somewhere didn't over- something. Either over-engineer or over-simplify, or over-use.
People get excited about technology and try to push the envelope on its usage. That's true of any widely used tech.
Hitting the golden middle is notoriously hard, especially when it is not the same middle for everyone.
> the whole ecosystem
What precisely do you mean? Sure Spring is notorious for this, but not the wider ecosystem.
Sure some libraries might not be using SemVer, but Maven itself predates it as well.
Nobody can blame them for choosing the right tool for the job, but many held them in contempt for license violation.