I am doing evaluation of feasibility of applying Rust for mission (life) critical large scale development of web API services.
Here are the main issues I discovered so far:
- futures crate type system exposes too much of the internal complexity (see Will 'impl Future' replace return types of combinators, like map and and_then?). Complexity is the main thing we battle with, what helps us to achieve relatively low (or no at all) rate of bugs
- executor and event polling threads should survive panics raised
- inside of execution of future chains (see How to recover future chain from panic! (need to close security vulnerability for http server)?) AND
- during construction of a future chain (see Place #1 marked here: Recover from panics and errors in future chains). Currently I am concluding it is not possible at all, or not possible to make it easy. This issue was mentioned above by @tjamaan
- recent standards (TLS, HTTP2, websockets) with all features included and supported by default by Hyper (see quite long-running ticket https://github.com/hyperium/hyper/issues/304)
- complete configurability of HTTP servers (at the level of Jetty or Vert.x in java)
I have not touched during evaluation, but the following is going to be important:
- database drives with async (futures) bases API for remote databases (i.e. client-server architecture)
- high-performance SQLite database driver WITHOUT async API
- kafka client
The following is going to be needed eventually, but less important:
- raft consensus protocol integration
- docker API clients
Some of that we may contribute to if there will be enough buy-in in Rust from all involved parties, but certain threshold of "readiness of Rust" is required.
Hope it helps