For the purposes of this discussion I am staying away from actor systems. I see actor systems a opt-in. So hypotheticaly speaking if you thought a Mio based solution had too much latency jitter you could switch to an actor-model where you have more control over the scheduler. But systems concepts (system in the cybernetics/server/architectural sense not low level system) are generic enough to apply to anything with multiple components.
So no. I would like a way to build any rust binary and have at my disposal enough building blocks to build a system that is reliable in the face of faults. Rust already goes a huge way in this direction in a) removing multiple classed of bugs b) valuing simplicity c) Types like Option and Error d) Saf(er) shared state if you want it etc.
But the story stops at a panic. Its up to the dev to build a system around it to recover or what most projects appear to be doing is to favour the hard reset (failing fast is not a bad choice but currently it feels like the only one).
I think the issue was all the book keeping around the connections between threads. I used a worker thread that wrapped a function in
catch_unwind and then sent a message up the supervision tree via a channel. This is quite crude. It also very quickly becomes a distributed system problem and I have to start worrying about consistency. Such worries are inevitable but I felt dirty solving these problems with channels. I see a way of improving this for users of the Tokio project - its poll semantics give me a point in the flow where I can inject a control plane i.e. the top level event_loop is first checking for control messages from the supervisor before polling the application stream.
I would be wary of any attempt for process like patterns outside an actor model. It should be about patterns of threads and a hierarchy of tasks of work. (Some might define this as a process pattern and I am happy to do so but I don’t want to be accused of trying to reintroduce actors).
I will see if I can open source parts of the work I am doing and get back to you on this. In the mean time tokio seems like the right practical project to focus on. My problem here is any solution will be specific to a futures based system.
Rust’s language documentation gets top marks from me I enjoy the communities insistence on good docs. Now with Tokio anyone has a template for doing server systems. If anyone need someone different then I am going to assume that they know what they are doing and don’t need any documentation from the Rust team up and above the lang docs and the Rust Book.
A question for you:
In your opinion what are the pain points for building distributed systems (or just servers to stay on track) in Rust?
In your opinion what are the pain points for operating Rust in production?