> For line of business apps, it is inaccessible and the safety dial is turned up too far.
My employer has a "line of business app" written in Rust. Here's what we're learned:
1. Rust does have a learning curve. It's easier to learn to use well than C++, in my opinion, but certainly harder than Ruby or Java. You really, really need to budget 2 weeks for turning an existing C++ developer into a productive and confident Rust developer. You can't take somebody who doesn't know the difference between "stack" and "heap", or who has never passed an anonymous function to "map", and expect them to bang out code rapidly in two days.
2. The library situation for business apps is just barely adequate. We need support for PostgreSQL, RabbitMQ, REST APIs, etc. In each case, high-quality libraries exist, but they're usually missing something. (For example: For PostgreSQL, we need to use both 'postgres' and 'diesel' to get the feature coverage we want. For RabbitMQ, we don't have heartbeat support. For REST APIs, we won't have good HTTP request mocking until the Hyper async stuff sorts itself out. And so on.)
3. The Rust code is just ridiculously fast. We're processing gigabytes of data, so we love this.
4. The Rust code is remarkably "trustworthy", and I'm not just talking about memory safety. If your program even compiles, it almost always works correctly (assuming you understood the spec). This has at least as much to do with Rust's 'enum' and 'match', which encourage people to enumerate and handle all cases, as it does with the borrow checker.
5. Rust code is very pleasant to maintain and refactor once written.
Overall, we like Rust, but we're mostly only using it where (a) we really want performance, or (b) we really want to make sure we handle lots of tricky corner cases correctly. Oh, or (c) for long-running jobs that take hours to run on real data, where compiler correctness-checks are a huge win. We'll probably gradually use Rust in more places as we get experience and the tools mature.