The only problem is that the compiler is very slow now, so it doesn't scale to large code bases, which is a no-go in my company. Hopefully the Rust team understands that this is not only a would-be-nice to have feature (I see learning the borrow checker as a smaller problem)
The way of working with that is use cargo check command which is much faster and splitting your problem into multiple crates so you don't have everything in one giant project. Which is what tends to happen in large code bases anyway.
Also they are putting quite a lot of work into making it faster. Before you get to that large code base it will be better.
https://www.wired.com/2015/09/google-2-billion-lines-codeand...
I've been using Rust heavily for 10 months. I think that if you want to use it for web stuff you very much can, but the language is more immature than it might first appear. If the community keeps going the way it is, I hope to work with it commercially by 2020.
The most promising things I've read about it as a serious systems language are from Cambridge Consultants [1,2], but there's a lot of ongoing work to make it ready for embedded work.
[1] http://blog.cambridgeconsultants.com/wireless-product-develo...
[2] http://blog.cambridgeconsultants.com/wireless-product-develo...
Java, C#, Go, Haskell, OCaml are much easier to ramp people up with and hire for.
And then there's the environmental cost of slower code. How many tonnes of CO2 emissions are higher level languages responsible for daily?
Sure. If it's just as easy for the task then why not?
But I wouldn't recommend Rust for web development for the same reason I wouldn't recommend C++ for web dev: complexity. Obviously, this is entirely subjective but I don't think either language will ever be easier to write than Java or C#, especially for beginners.
I used to TA a freshman data structures class. I can't imagine ever going to a class of new programmers and trying to explain to them when to use Rc<RefCell<Vec<T>>> vs. Rc<Vec<RefCell<T>>>.
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) 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.
I'm interested - how do you teach it? I would have thought that the type system could make these things easier to visualise rather than harder, but then I don't have teaching experience.
At the moment a lot of hobbyists are doing web stuff in Rust. Commercially I think usage would be in the same vein as the common pattern of rewriting Ruby services in Go if it starts to limit performance.
If you've got a particularly hot lambda function, rewriting it in Rust is a pretty simple way to save a bunch of money.