Why and Why not Rust?

[jbe]

@ZiCog

Re: "Memory efficient" - I wonder what you mean by "not program size". People are using Rust on tiny micro-controllers Even down to the AVR's that have very little memory. Ciff Biffle has such an example, producing VGA graphics from a micro-controller that is smaller than his C version.

I feel like many Rust programs have a large binary size, e.g. due to monomorphization. However, this is an advantage in execution time.

Also, typically Rust programs come with a lot of dependencies. Having hundreds of dependencies is not unusual. (Of course that's the same for many other languages with exhaustive ecosystems.) I think it's possible to program more "lightweight" though (and Cargo's features certainly help).

@jbe

Please insert Hello World, Disc 2, and press any key to continue.

See also this follow-up.

@ZiCog

Re: "Difficult to master" - Mmm...compared to what? C++ is so complex nobody can understand all of it's features and how they interact with each other. The likes of Occaml and such are beyond me even after at a few attempts. Even Javascript has enough gotchas to have people scraping their heads for a long time.

You could compare Rust to languages which have lesser language constructs and which are better documented. Of course these other languages have other cons, but certainly, they are easier to learn. Just to name an example, completely understanding Lua is possible within 24 hours. For Rust, I would take years if I consider topics such as pinning, async, lifetimes, aliasing rules, threading, traits, closures, dyn vs impl, supertraits, recursive structures, error handling, channels, synchronization, drop handlers, stack unwinding, reference counting, subtyping, variance, etc. etc.

@ZiCog

Re: "error handling sometimes feels like having a lot of friction". Again, compared to what? I find Rust's error handling far nicer than the chaos of exceptions in other languages or the total lack of error handling in others.

I found out that when APIs use callbacks but don't provide a fallible variant for them, then they will simply not support error handling at all (other than panicking). This made me wonder if it has been a good idea to not use exceptions for error handling. See also: Closures in API design – theoretical limitations and best practices?

std deals with this by providing multiple methods, e.g. Iterator::try_for_each in addition to Iterator::for_each. When writing code yourself, that gets you back to the issue of boilerplate, as I mentioned above.

So maybe languages which support exceptions are better in that matter (because they circumvent these problems)? I don't know. I felt like I spent a lot of time dealing with (and working around) issues regarding error handling in Rust – at least when I tried to do it in a well-structured way.

@ZiCog

Re: "complexity of the language leads to inevitable design flaws in std" Perhaps. On the other hand that is not unique to Rust. The "simplicity" of C lead to it having horrible API's in its standard library. For example all the "strxxx" routines.

Yeah, C is certainly not better in that regard. I wonder though, if there are other complex languages which do a better job at fixing mistakes in their standard library.

On the pro-side, I would like to add that Rust does fix flaws in the language itself while maintaining backward compatibility by using Editions, which I really like.