The reason you're "hearing so much about Rust" is that they are less shy about hype marketing [(ex)](http://forum.nim-lang.org///www.redox-os.org/fr/news/rust-is-softwares-salvation-17/) (and, ironically, they go irate when they come across evangelists for a competing language [(ex)](http://forum.nim-lang.org///forum.nim-lang.org/t/2687)). Yes, many people are very religious about their choice of programming language - including myself. ;)
I don't see how Nim would benefit from a Rust _backend_. The C backend serves almost the entirely of Nim's purpose. From what I understand, the C++ backend makes it a bit easier to build wrappers around C++ libraries, but isn't really a necessity. When it comes to good libraries, I'd guesstimate that C probably has about 85% market share, with 14% of good libraries being C++ only (rather than OO wrappers around C), and 1% "other" (with Fortran still being ahead of Rust). IPFS's libp2p being implemented in Go is a strange exception, but they [will eventually write an implementation in C/C++](https://github.com/ipfs/ipfs/issues/164). (One exception is the JS backend, which is categorically different. It still needs a lot of work to reach its potential (with more libraries that work in both in-browser and outside-the-browser contexts, leveraging things like [BrowserFS](https://github.com/jvilk/BrowserFS), etc), and it may not be a good choice for most people anymore if/when [wasm](https://en.wikipedia.org/wiki/WebAssembly) matures.) Back when Rust's Mid-level Intermediate Representation (MIR) [was announced](https://blog.rust-lang.org/2016/04/19/MIR.html), I've inquired on IRC [(log)](http://forum.nim-lang.org///irclogs.nim-lang.org/27-04-2016.html) about the possibility of a unified library ecosystem between Nim and other similar languages - that is a very interesting discussion IMHO, but a very different idea from a "backend".
