I have a feeling it is actually not possible because of the borrowing stuff somehow. But I keep hearing so much about Rust.. it seems so many C or C++ programmers are becoming Rust evangelicals. It also seems like they are still either deliberately making it difficult to handle normal tasks in Rust or they just don't know how to make a clean syntax or streamlined system.
So I have finally accepted that I will have to learn Rust eventually. But just in case there could be hope down the line I am asking this question. Thanks.
The reason you're "hearing so much about Rust" is that they are less shy about hype marketing (ex) (and, ironically, they go irate when they come across evangelists for a competing language (ex)). 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++.
(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, etc), and it may not be a good choice for most people anymore if/when wasm matures.)
Back when Rust's Mid-level Intermediate Representation (MIR) was announced, I've inquired on IRC (log) 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".
I think a Rust backend for Nim would be quite interesting. In my experience, I've found Rust is more like C than any other language, so I'm quite sure it would be possible.
There is already a C to Rust translator named Corrode. It would be an interesting experiment to compile one's Nim code to C, then use Corrode to translate the C code to Rust. I suspect, however, that would simply implement the Nim garbage collector in Rust, rather than leverage Rust's borrow-checker, ownership, and lifetime features.
I suspect, if the stewards of Nim ever wanted to add a Rust-like borrow checker to Nim, using Rust as a backend could potentially be part of the implementation.
EDIT: Some else had a similar idea: Rust the New LLVM
I've been thinking about this more, so I have a few more thoughts.
Rust's compile-time memory safety guarantees are the feature to beat. I've spent a large part of 2016 exploring Rust, and I hate it, but, the compile-time memory safety is such a compelling feature, I'll suffer through it and keep using it. Even Swift is planning something Rust-like in v4.0.
Would there be any advantage implementing a Nim backend in Rust maintaining all of Nim's features? I'll argue "yes". If the implementation pendantically avoided Rust's unsafe feature, one could guarantee (at least in as much as Rust can make such gurantees) that if their code compiled, their code would be memory-safe. That's worth it, in my opinion. I do have to admit, however, that I don't know to what extent Nim already provides such gurantees.
It would introduce a number of unfortunate disadvantages. To name two: Probably less performance than the C backend, and very slow compile times.
I've been using Rust for a bit lately, and I rather like it. However, compiling Rust is painfully slow, even for the smallish things I'm doing. Until it's very fast, I think compiling to Rust is an awful idea for Nim. Nim's quick compiler is a big benefit IMO.
I rather disagree with @Krux02; the LLVM backend (which must be what @Krux02 refers to) is developed independently by @arnetheduck and I doubt that Araq spends much time on it yet at all. However, looking at D, the LLVM backed compiler is the one that generates the fastest code, and I hope that maybe one day we'll see the same from the Nim LLVM backend.
Rust is not just advertised better than Nim. They announced a date for Rust 1.0, and explained what it means, and they've been pretty good about holding to it and then having new releases every six weeks. That's impressive. I prefer Nim as a language, but I believe that the future for Rust looks more assured than that for Nim.
If the implementation pendantically avoided Rust's unsafe feature
This isn't doable. Following Rust's ownership and lifetime rules requires explicit annotations ... they can't be inferred by the compiler, or else the Rust compiler would already be doing that (it does do it when it can, but that leaves all the cases when it can't, and generating code from Nim source would hit all those cases).
There is already a C to Rust translator named Corrode.
Note this critical fact: "its output is only as safe as the input was"
This is essential, and why this talk of leveraging Rust's memory safety is misguided. Rust does not give you memory safety; rather, it gives you an annotation system which allows you to create provably safe programs. Remember that Rust is focused on "zero-cost abstractions" ... that means that its features don't add runtime code or memory overhead. It's all done at compile-type, through static type checking. Static type checking is a restriction on what is a legal program. Trying to target Rust's type system in the generated code would just mean a lot of failed compilations due to Rust's borrow checker rejecting the code.
Some else had a similar idea: Rust the New LLVM
It's a good idea to read that to the end, and not just read the advantages:
For my dream to become reality, we need a lot of work to develop Rust as a compile target, both on the Rust compiler and on compilers targeting Rust.
In other words, Rust is not currently a suitable backend target.
Also, looking carefully at the "advantages", the only one that actually is an advantage is the package system, and it's only an advantage if you are willing to enslave your language to the Rust ecosystem. Having an advanced type system in your target language is a negative ... Nim has its own type system, and the code generator would have to go to pains to avoid Rust's.
Rust as a backend language is only advantageous to writing a compiler for a new language specifically aimed at providing a type system and memory safety compatible with Rust's. The author of that "Rust the new LLVM" article is writing such a language, Lia, but note:
type LiaAny = Rc<RefCell<Rc<RefCell<Box<Any>>>>>;
All values in Lia (integers, closures, etc.) have the type LiaAny.So sure, if you're ok with all your integers being boxed and doubly reference counted then you can use Rust as a backend.
Even Swift is planning something Rust-like in v4.0.
No, that's not what it says. They note that an optional Rust-style memory ownership model is "highly desired by systems programmers" -- i.e., they hear all the buzz -- and they note that this would have a large impact on the ABI, which they aim to stabilize, so they "need a comprehensive design". They explicitly state "a full memory ownership model is likely too large for Swift 4 stage 1". I would be very surprised if a memory ownership model makes it into Swift 4 at all, but they may add some features to the ABI to pave the way for one.
I wonder if it is possible to automatically wrap rust libraries, to make them usable in Nim. What I mean is something like this:
rustimport myRustLib
echo myRustLib.foo(123)
with myRustLib being a pure rust library. No glue code should be required to be written manually. With C that is not possible, because C does not have modules. For C one has transform the header to a Nim equivalent for a clean module, or one can just exploit the fact that Nim compiles to C and emit calls to the include and the C function calls. c2nim is a tool that can help a lot for the process to translate the C header, but it is something that cannot be implemented 100% correct, and therefore there will always be manual written wrappers. But Rust does not have this disadvantage, there are clean modules and maybe a compiler plugin can give you all the information you would need to generate the required Nim wrapper code 100% reliable and 100% automated.
This would really help to take an advantage of the always growing Rust community.