Discussion on: Nim v. Rust

Some notes:

First, you don't need the turbofish in your Rust. Rust's type inference is really powerful, and in the following code:

use std::io;

fn main() -> io::Result<()> {
    let mut input = String::new();
    io::stdin().read_line(&mut input)?;
    let number = input.trim().parse().unwrap();
    for i in 0..number {
        println!("Saying hi for the {} time!", i + 1);
    }
    Ok(())
}

It still can understand that number is an integer (due to it being used in the range).

Second, Rust can compile to JS, too 😃. This is thanks to LLVM - any language compiled to LLVM IR can be converted to asm.js or WebAssembly.

Second, the ? operator is not a shorthand for .expect() nor .unwrap(); it's desugared like this:

fn f() -> ReturnType {
    let _value = expr?;
}
// Desugared into:
fn f() -> ReturnType {
    let _value = match ::std::ops::Try::into_result(expr) {
        Ok(v) => v,
        Err(e) => return ::std::ops::Try::from_error(From::from(e)),
    }
}

Third. The typing "boilerplate" the Rust code has compared to Nim in the example is just due to the ability to omit main() in Nim. Of course, in real-world program there isn't a difference.

Fourth. Rust has really powerful macro system, too. You've chosen to use a library that doesn't use that, and that's OK. There are people that prefers this style (I too, in most cases). But even if there aren't libraries that allows you to write code like your Nim server, this is clearly possible.

Fifth. I don't know Nim much, but AFAIK it has exceptions. Rust could have exceptions, too (in fact, you can simulate them), but there is a reason it chose not to do so. Exceptions are really, really bad in production. Decades of engineering proved that. They're really "you can't without them, but you also can't with them".

Sixth. Not having GC is really an advantage for Rust. Reference counting bring Nim closer to Rust (it also has some form of it), and can be better for system programming (because of the GC's latency), but still adds overhead. For each store. Rust, not only it can eliminate the need in most of the cases due to compiler's excessive knowledge about the program, also idiomatic Rust almost doesn't get to this situation because of the ownership and borrows.

Seventh. The biggest advantage of Rust is its safety. Rust wasn't created to answer the need for a modern system programming language (although it answers it too), but to answer the need of a safe system, concurrent programming languages. Again, I don't know Nim, but from what I've read about it, it doesn't deal with this problem at all.

Eighth. Rust isn't Python, and it's not good for small programs. The advantages of an intransigent compiler become obvious as your project grows. Ask the folks at Microsoft about the need in TypeScript and the ever growing ecosystem around it - static typing over a dynamically typed language!

Ninth. Syntax is really matter of preference, and one can claim that C's syntax is the worst invented. But anyway, the people that program in Rust are not students; they're people working at REALLY big projects. Those already have experience with C-like languages. The fact that almost all (if not all) mainstream languages use C-like syntax is not accidental.

Tenth and last, but certainly not least. Rust is more mature. With a big difference. The users are more, the packages are more, and the ecosystem is enough to build real programs. The fact that several big companies use Rust in their big projects at least not disturb that. Nim ecosystem, although older, is not there. It can get there, eventually, but if you ask for my guess - it won't. There isn't enough space for many system languages, and this area in the industry is changing very slowly. Nim could be a great language to replace, say, Java and C#, but it doesn't aim there. And I think there is a room for one, and only one, language to replace C/C++.