I'm not saying this makes Rust as easy as Java or C#, but I don't think `Rc`/`RefCell` types are the cause, nor for that matter the solution to the cause. Idio

I'm not saying this makes Rust as easy as Java or C#, but I don't think `Rc`/`RefCell` types are the cause, nor for that matter the solution to the cause. Idiomatic Rust makes single-threaded interior mutability very, very rare. I don't remember ever once encountering the dilemma of "Vec<RefCell<T>> vs RefCell<Vec<T>>", in my own code or elsewhere. In fact, my current project (https://github.com/team-worm/spice https://github.com/team-worm/spice) involves an HTTP server written in Rust. Like you suggest, managing state across requests was one of the harder parts (both for myself to work out fully and for a team member who started with no Rust experience to grasp). However, much of that difficulty was intrinsic to the problem- the HTTP library we use is multithreaded, so for correctness we have to synchronize access to the state. Instead of discovering this by way of race conditions or hard-earned experience, Rust enforces it for us. Team members who have never used Rust before can be trusted to go in and work on the server without worrying about causing subtle concurrency bugs. They hit the brick wall of error messages instead.