The pitch for this framework is that you decorate a Python function, call it slightly differently, and it runs across a cluster. That pitch is broadly true, which is impressive, and the documentation is at its best when it is explaining the small number of ideas that make it work. There are essentially two primitives. A task is a stateless function that runs somewhere in the cluster and returns a reference to a future result.
An actor is a stateful process that lives somewhere in the cluster and that you send messages to. Almost everything else is built from those two ideas. The core concepts documentation explains them properly, including the parts people get wrong, such as the fact that calling a remote function returns immediately with a reference rather than a value, that you have to explicitly wait for results, and that the shared object store means large objects are not copied between workers on the same machine. Those pages are worth reading as an education in distributed thinking regardless of whether you use the framework, because the same concepts appear in every system of this kind.
The scaling story holds up. Code written to run locally really does move to a cluster with minimal change, which is genuinely unusual, and the documentation shows the progression from a laptop to a multi node cluster honestly rather than pretending the difference does not exist. Of the libraries built on the core, the hyperparameter tuning one is the standout and its documentation is the best in the set. Search algorithms, early stopping of unpromising trials, scheduling across available resources, and integration with the common training frameworks.
If you have ever run a grid search by writing nested loops and then waited three days, this library and these pages will pay for themselves quickly, and it is worth adopting on its own without any of the rest. The serving documentation is also better than the average in its category, because it engages with the awkward parts of deploying models rather than the demo path. Composing multiple models into a pipeline, autoscaling in response to load, batching requests to use hardware efficiently, and mixing CPU and GPU stages in the same deployment. These are the actual problems in model serving and they are addressed.
Now the criticisms. The sprawl is the first thing you notice. Core, data processing, training, tuning, serving and reinforcement learning, each with its own conceptual model, its own idioms and its own documentation section, and the boundaries between them are not always obvious. A newcomer trying to work out which part of this large thing solves their problem faces a real navigation cost before any learning starts, and the front pages do less than they should to route people.
Debugging is where the documentation lets you down most and it is not a small gap. Distributed systems fail in ways that single process programs do not. A worker dies and takes state with it. A task hangs and nothing tells you why.
Something exhausts memory on one node and the error surfaces somewhere unrelated. Object references outlive what they point to. These situations are the actual daily experience of running distributed workloads, and the material on diagnosing them is thin relative to how much time you will spend doing it. The dashboard and the observability tooling get described, and the reasoning process for a failure that only manifests at scale does not.
The object store deserves more attention than it gets. Its memory behaviour, when things spill to disk, how references keep objects alive longer than you expect, and how that interacts with a data processing job that is streaming more data than fits in memory. This causes a lot of real problems and the documentation treats it as an implementation detail. Commercially, the managed platform is present throughout, which is the standard arrangement for open source backed by a company.
The framework is fully usable without it and the funnel is visible. And the honest caveat, which applies to the whole category, is that most people reading this do not need it. A single machine with a lot of memory and a modern GPU will handle a surprising amount of work, and the operational cost of a distributed system is real and permanent. Reaching for this before you have exhausted one machine is a decision that will cost you more time than it saves.
My three point five is for an elegant core with genuinely good conceptual documentation and an excellent tuning library, held back by a sprawl that makes the whole thing hard to approach, by thin coverage of the debugging problems that dominate real use, and by being the right tool for far fewer people than it appears to be marketed at.