One big advantage of Go is that core packages exist for most of the things you might want to do on a server. Those packages are mostly maintained by Google employees and are used within Google, so the packages are exercised and maintained. Rust, like Python, has a large collection of packages maintained by random people and not under organized maintenance or testing.
"Corrode" needs to get a lot better before it is useful. Look at the Rust it generates.[1] It transliterates C into unsafe Rust. That's not too helpful. Doing such a translation well is a hard problem. The translator will need to figure out exactly what needs to be mutable where, which means building a graph of the program across function boundaries.
> It transliterates C into unsafe Rust. That's not too helpful.
From the author's perspective it is helpful. If the goal is to make an existing C project memory safe without sacrificing performance and memory efficiency, one way to do that is to rewrite it in (safe) Rust. An automated direct translation from C to (unsafe) Rust would result in a body of code that would not (completely) satisfy the borrow checker. But some significant portion of the code would, thus reducing the total work necessary to translate the project to safe Rust.
The thing is that you can satisfy the borrow checker by (manually) modifying the Rust code resulting from the automated translation, or, alternatively, you could modify the C code in such a way that the automated translation results in Rust code that satisfies the borrow checker. If you can manage to write C code that automatically translates to safe Rust, then the safety guarantees of the borrow checker also apply to the C code.
So the automatic translator can be used to apply Rust's borrow checker (and its safety guarantees) to C code. This would be one way to, for example, bring a degree of memory safety to embedded platforms that are not supported by Rust, but which do support C. Pretty sneaky, no? (Of course, some of Rust's memory safety is achieved through run-time checks rather than the borrow checker, so it doesn't completely solve the problem for C.)
But satisfying the borrow checker is still a lot of (mental) work, and as I've pointed out, there is an easier alternative. It would be much easier to write an automatic translator from C to SaferCPlusPlus[1]. And even for embedded platforms that don't support modern C++ (or at least its standard library), you can pull the same trick, as SaferCPlusPlus also uses a degree of static enforcement of memory safety (although not to quite the same degree as Rust's borrow checker.)
The first step would be to make everything const that can possibly be const. Const stuff can be borrowed non-mutably. Then make all variables have as narrow a scope as possible, even if this means putting in more bracketed blocks. Variables which are not initialized at declaration should be combined with their first assignment whenever possible.
Then you have to analyze what can have single ownership and what can't. Non-single-ownership data has to be refcounted. That makes the borrow checker happy, but may result in excessive refcounting if the analyzer can't track usage through complex code.
Pointers need to be analyzed for usage. If there's no pointer arithmetic, it can become a Rust reference, maybe with a "Some" if it can be nil. If there's pointer arithmetic, the pointer is going to have to be represented as a reference and a subscript.
You need a standard C library in Rust, with Rust safe equivalents of all the string functions.
It's a big job, but not impossible. It might be a marketable product.
"Corrode" needs to get a lot better before it is useful. Look at the Rust it generates.[1] It transliterates C into unsafe Rust. That's not too helpful. Doing such a translation well is a hard problem. The translator will need to figure out exactly what needs to be mutable where, which means building a graph of the program across function boundaries.
[1] https://www.reddit.com/r/rust/comments/4rv0uh/early_stage_c_...