Rust is a fantastic C replacement. It is nowhere near being a replacement for higher level languages in terms of productivity and ease of use.
YMMV.
However, I don't think Rust is a more productive general programming language than Ruby/Python. I think Rust is more productive when solving systems-level concerns, but most problems aren't systems problems. Crystal is also looking to be a nice compromise for a productive, C/C++ level performance language (if the ecosystem catches up).
The mental effort of writing Erlang is an order of magnitude lower compared to Rust. While Rust is more fun, it does not and can not come close.
I'm not much for Java/Python/Ruby. I don't see those as productive as Erlang so Rust may be closer.
I find personally that if there are libraries to help me out, I'm only slightly slower in Rust than I am in Ruby, but then there's no debugging time in Rust, and invariably, there will be tons of work I have to do later with the Ruby to shake out bugs.
YMMV.
Despite the fact that I chose to do this in Python, I'm not at all sure I wouldn't have had a working solution faster in a language that had a good type system and a error handling strategy that made errors explicit and forced them to be handled. I'm almost certain that writing in Rust would have ended up with something that was more reliable in the long term.
(FTR I imagine that Go may also have been a reasonable choice for this kind of work, but I haven't used it).
Rust is quite a good language though, I'll admit that, I'm currently learning it by way of writing a kernel in it. But there are more productive languages out there.
When working that low level, there are a lot of lifetime issues your going to need to manage, and that can definitely make Rust have a higher cognitive load.
On a side note have you looked at this blog series? https://www.tockos.org/blog/2017/apsys-paper/
They’re definitely paving an interesting path in the kernel space for Rust.
There is also plenty of unsafe stuff that won't go away or stuff that is unsafe not because of the code but because x86. For example, you can't properly handle a null pointer in rust, however, at low-level, the pointer 0x00 is completely valid and I hate to have to waste that address because Rust and LLVM won't allow it.
The major reason I even bothered to learn Rust for this way because I didn't want to manage all of this in C on top of having only printf as my debugging tool.