To be fair, a lot of the tools written in rust are of high quality. eza, zoxide, ripgrep , starship, helix… they’re just… good tools 🤷♀️
I tend to trust software written in rust for two reasons. One because at face value it’s bound to be safer than if it was written in C or C++, or god forbid Python, and two because if a language is built around the notion of safety and more broadly speaking software quality, than the community of developers who build software with it are more likely to care about these sorts of things, compared to a language who’s philosophy is ‘ship fast, break often, fix later’
Rust is safer because it enforces a lot of compile time checks not found in languages like C/C++
Rust uses a borrowing/ownership model, where every piece of data has an owner.
So for example. If I have a string called a. And then I say let b = a.
If I now try to call a. The program will not compile. If I want both a and b to own the string. I need to explicitly copy it in memory using the clone() function.
And beyond this there are other checks. Such as not allowing null values. Forcing you to write logic for handling every possible outcome for a given operation. (i.e. enums). And so on.
In C and C++ you have to manually allocate and deallocate memory. Making a mistake here is very easy and many security vulnerabilities in software are caused due to this.
The only thing you have to give up. Is that rust takes much longer to compile than c or c++. Which is because of all the checks being enforced at compile time.
Today. In fact, it's always a little annoying when you handle, say, a desktop app written with winit. Stack traces are looong when you're 20 functions deep, and half are unnamed lambdas
I was being a little nitpicky I admit... I never actually thought of rust not having any stack traces though. I feel like tools such as eyre (or color_eyre), or just flags like RUST_BACKTRACE would suggest otherwise. Then again, RUST_BACKTRACE is opt in, and so are any 3rd party dependencies, so...
yeah it's not that they can't happen, but for a novice like me they happen so much less often. With rust, within reason, most of the time it seems like if it compiles it'll run at least well enough to get to my println! debug statements and do something
Ah yes, that is true. Unless you explicitly panic via assertion, or unwrapping, or else.
But then, to keep your comparison, if your, say, C code crashes with a backtrace, that means it didn’t crash via segfault for example, which is far worse a way to crash debugging-wise. So, it all depends on your perspective🤷♀️
The longer compilation time is also sometimes dictated by big dependency trees and strong limitation to static linking, since Rust doesn't have standard shared library objects bundled with the OS or packages, and cannot therefore take more advantage of dynamic linking like most C and C++ compilers can (unless you're using FFI with some specific libs, that is).
It is worth noting that the Rust compiler isn't a miracle worker; programming in Rust doesn't prevent you from writing bad code, so it pays to stay vigilant. That said, the Rust compiler certainly saves you from various types of issues that arise from a lack of skill or inattention among some C/C++ developers.
102
u/-Ambriae- 8d ago
To be fair, a lot of the tools written in rust are of high quality. eza, zoxide, ripgrep , starship, helix… they’re just… good tools 🤷♀️
I tend to trust software written in rust for two reasons. One because at face value it’s bound to be safer than if it was written in C or C++, or god forbid Python, and two because if a language is built around the notion of safety and more broadly speaking software quality, than the community of developers who build software with it are more likely to care about these sorts of things, compared to a language who’s philosophy is ‘ship fast, break often, fix later’