I was playing around with trying to do this a while back (while also trying to learn Rust some), and it felt very cumbersome to have to write many specific Diesel update methods to handle different types of requests. It could have been my now knowing a better way to accomplish it, or it could have been the type of queries I was trying to model aren't a good fit for a staticly typed system like that (and there may be a better way to architect it). In any case, it felt like I was poorly approximating the strict typing I had already implemented in Postgres, a few times over, when I would be happy just handing it to Postgres and letting it throw out errors as needed.
As for redis, I use it as a dumb KV store, no need for an abstraction layer.
But love it, and love the team at Dgraph/Badger.
Isn't that a contradiction?
I would be refactoring in any language - the idea behind the service, the requirements, etc, are changing a lot as I'm building these services out. These are external factors that would exist regardless of the language, as I continue to explore the problem space.
I'm extremely productive in Rust vs other languages, especially for young projects where I spend a lot of time refactoring. Things like borrow checker errors just don't happen very often to me anymore, or they catch legitimate bugs and are generally quite easy to fix. I just don't run into them very often at this point.
I've written Python and Java professionally. In both cases I felt like I just couldn't express what I wanted to, at all times, in my program. This led to me being a lot less comfortable refactoring - relying on tests that were far too heavily tied to implementation details.
I had some really complex logic I needed to write for one of my services. Basically I needed to represent a 'thing' and that 'thing' could be in a few different states. I wrote out the code, types first, so that every state had a type. I was able to do this generically using Rust's associated types in a way that allowed me to implement the state machine for multiple 'things'. It was very testable, very readable code that I had high confidence in. I would have had a much harder time doing this in Java/ Python (I have done similar things, and you can get value from the approach, but not the same level). I've refactored that code a lot with confidence.
Speed is a nice bonus, but mostly secondary.