Re: Any possibility of a Rust backend for Nim?
@Krux02 That sounds like a good idea; certainly something worth looking into.
Re: Any possibility of a Rust backend for Nim?
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.
Re: Any possibility of a Rust backend 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.
Re: Any possibility of a Rust backend for Nim?
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.
Re: Any possibility of a Rust backend for Nim?
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](https://github.com/apple/swift-evolution). 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](https://doc.rust-lang.org/book/unsafe.html) 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.
Re: Any possibility of a Rust backend for Nim?
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](https://github.com/jameysharp/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 every wanted to add a Rust-like borrow checker to Nim, using Rust as a backend could potentially be part of the implementation.
Re: Any possibility of a Rust backend for Nim?
Hmm, double-posting forum bug - [https://archive.is/H6iJw](https://archive.is/H6iJw) (I self-deleted the dupe.)
Re: Any possibility of a Rust backend for Nim?
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".
Re: Any possibility of a Rust backend for Nim?
As far as I know, you can always disable the safety belt of Rust when you need to. It is already required to interface C from rust. I personally am not the fan of the feature that Nim can compile to any language in the world. I think that a lot of work to implement, and even more work to maintain. The C backend is a very common way to implement a new language, and reusing a lot of knowledge about the language C. C++ backend is just because it is easy to support. EcmaScript is important, because WebAssembly is simply not there yet, and it could take a while before it really is suitable. All other backends are in my opinion a distraction from getting the important stuff fixed to get Nim to a stable version 1. Every backend that is not one of the mentioned backends should get lowest priority.
Re: Any possibility of a Rust backend for Nim?
What is the point? You can't use the tools that rust provides to handle memory with safety, arguably the only reason to use rust over nim.
Any possibility of a Rust backend for Nim?
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.
