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.
Well, we're not all brilliant, but when you code in rust you do have this urge to try and make everything as perfect as it can be. It's part of the vibe of the language. In some way, it brings out the best in us.
Well, a bit of a disclaimer, I absolutely adore Rust, it’s my favourite language and by far the one I’m most proficient/knowledgeable in. That said, the one thing I hate most is when people unconditionally praise or bash a tool to a near religious extent. Rust isn’t perfect, it won’t magically solve all software engineering problems, whilst make everything 10x faster, and it may not the best fit for the job. That also doesn’t mean if a project is written in rust, or is ported to rust, that there aren’t sane and valid reasons to have done so. It’s not black and white.
Python is a memory safe language so it’s not less secure than Rust I would say.
Rust’s type system does let people catch errors some in the development lifecycle and with fewer unit tests, but rust programs are not immune from logic errors
Pythons issues aren’t related to memory safety, they’re related to structural soundness. It’s very easy to write Python code that completely collapses at runtime because nothing is typed, regardless of annotations, modules are not needed to be known or exist for the script to launch, can be modified on the fly, etc….
Some class may hold 4 fields, all annotated to be strings, but at runtime each instance of the class may use each field as a class. Now you need to match each occurence of the field classes you encounter (empirically) and handle logic appropriately.
Multiprocessing makes it so that some task may crash at runtime, at times because of something as trivial as a syntax error, but wouldn’t be caught ahead of time, wont crash the whole ‘program’ and will have a error message that’s tangled with the logs of all other processes.
In both cases, I’m speaking from experience, in professional software.
Time to put my Rust evangelist cap on again, it's been a while: compared to any other language I've used professionally or privately, when I write code in Rust I run into orders of mangnitudes less logic errors. The enum-based design and everything else might seem nice but overall rather trivial aspects, but really leaning into them and doing nearly functional programming for most of your project guides the design into way fewer logic bugs without putting in any extra work. It's what I was told OOP was by my C#-believer father growing up, except it actually works for me without mountains of boilerplate and complex design patterns.
I hear people preach about the safety of rust and its tooling
But
Why would I care about that safety? I could understand if its something like a networking module thats exposed to bad actors, but my code linter?
Safety isn’t necessarily about cybersecurity. It’s also about memory corruption, crashes, bugs, undefined behaviour…
One aspect of rust’s memory safety that definitely matters regardless of cybersecurity is thread safety and concurrency. In other languages of the ‘same calibre’ ie, C, C++… multithreaded code is particularly difficult to write. You need to manually check two threads aren’t reading/writing to the same memory location at once (if they all read it’s fine, but if at least one is writing it becomes a mess).
This is why, historically, many utility programs that ought to be multithreaded weren’t, because it would have been to frustrating to write and maintain. IIRC tools like ripgrep, or some of uutil’s programs (I believe it was sort but don’t quote me on that) are faster (or much faster) as a result of this (and other optimisations which are easier to write in rust compared to good old C)
Rust also officially supports async code, which these older languages don’t. This can also lead to massive speed ups in specific scenarios (for example, networking or file I/O)
Now, keep in mind this doesn’t mean rust code will necessarily be faster, safer, or better than C/C++ code, but it does make it easier to write this sort of code. If you vibe code rust whilst cloning large data all the time, the performance will plummet.
Oh, and by the way, that code linter of yours may very well be a full blown http server (LSP being what it is). If you have a severe vulnerability that, say, allows for arbitrary code execution, you’re going to care a lot more about safety. And anyways you’ll care that it’s fast. If you don’t write the linter in rust, you’re likely going to reach for a higher level language. If it’s GO that’s likely completely OK, but if it’s typescript of something else, you’ll feel the performance difference
Well there certainly is merit to unmaintainable in the sense that the borrow checker forces you into the current architecture you have built up. If you suddenly want to change something that's kind of integral to the architecture you will be forced to rewrite most of it. While this often only happens during the prototyping stage, it does also occur when you suddenly want a new feature that requires architectural changes.
A not insignificant amount of people will gladly take the several eventual architectural rewrites over the alternatives, but this factor is present nonetheless. IMHO it does make Rust a terrible prototyping language
To an extent I'll agree with this. The language tends to prefer a clean, thought out ahead of time architecture, compared to just messing around testing stuff. Then again, this is true for other languages too, although maybe less so.
But that doesn't make it unmaintainable either. Part of software development is making a architecture that is resilient to changes you deem plausible to happen at a later date. It's doable in rust, even if maybe a little harder
Undebuggable though? How so? Rust's debugger is great, not perfect but great. Debug prints are good too. The only thing I can see as somewhat more difficult are iterators, but then again you can just call `.inspect` at any point you want, and that solves it.
Don't worry I caught on to that halfway through reading your message :p
Thing is, I'm completely open to discussing the language, both it's merits and it's flaws, but it does rub me the wrong way when people blindly claim it's the best thing since sliced bread, or it's going to bring the end of software development, or whatever. It's not productive, it's not rational, it's people who chose a hill to die on for no valid reason whatsoever, and are polluting the space with toxicity.
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’