You get memory safety. That's about it for Security. Quality is in the eye of the beholder. maybe it's quality code? Maybe it's junk, who knows. Rust isn't magic that forces code to be quality code or anything. That said, the code in the Redox system is generally good, so it's probably fine, but that's not because it's written in Rust, it's because of the developers.
Any GC'd language(Python, JS, Ruby, etc) gives you the same memory safety guarantees that Rust gives you. Of course GC'd languages tend to go a fair bit slower(sometimes very drastically slower) than Rust. So really the memory safety bit of Rust is that the memory safety happens at develop and compile time, instead of at runtime, like a GC language does. So you get the speed of other "systems" languages, like C, C++, etc AND memory safety.
While I generally agree, the latest Android report suggests that rust developers get fewer reverts and code reviews are faster. This could mean that better developers tend to adopt rust or it could mean that rust really is a language where quality is easier to attain.
There’s some reason to believe that given how easy it is to integrate testing into the rust code base and in general the trait and class system is also a bit higher quality and it encourage better isolation and things like const by default and not allowing API that could misuse the data structure in some unsafe way. And it has a rich ecosystem that’s easy to integrate 3p dependencies so that you’re not solving the same problem repeatedly like you tend to do in c++
So there is some reason to believe Rust does actually encourage slightly higher quality code out of developers.
> Rust isn't magic that forces code to be quality code or anything.
It is not, but the language and ecosystem are generally very well-designed and encourage you to "do the right thing," as it were. Many of the APIs you'd use in your day-to-day are designed to make it much harder to hold them wrong. On balance, outside of Haskell, it's probably the implementation language that fills me with the most confidence for any given particular piece of software.
Most of the performance penalty for the languages you mentioned is because they're dynamically typed and interpreted. The GC is a much smaller slice of the performance pie.
In native-compiled languages (Nim, D, etc), the penalty for GC can be astoundingly low. With a reference counting GC, you're essentially emulating "perfect" use of C++ unique_ptr. Nim and D are very much performance-competitive with C++ in more data-oriented scenarios that don't have hard real-time constraints, and that's with D having a stop-the-world mark-and-sweep GC.
The issue then becomes compatibility with other binary interfaces, especially C and C++ libraries.
>You get memory safety. That's about it for Security
Not true, you get one of the strongest and most expressive type systems out there.
One example are the mutability guarantees which are stronger than in any other language. In C++ with const you say "I'm not going to modify this". In Rust with &mut you're saying "Nobody else is going to modify this." This is 100x more powerful, because you can guarantee nobody messes with the values you borrow. That's one very common issue in efficient C++ code that is unfixable.
Sum types (enum with value) enable designing with types in a way otherwise only doable in other ML-based languages. Derive macros make it easy to use as well since you can skip the boilerplate.
Integers of different sizes need explicit casting, another common source of bugs.
Macros are evaluated as part of the AST. A lot safer than text substitution.
Further the borrow checker helps with enabling compile time checking of concurrency.
The list goes on, but nobody that has tried Rust properly can say that it only helps prevent memory safety issues. If that's your view, you just showed that you didn't even try.
It's true for new projects.
For rewrites (such as a shell) it can mean a lot of regressions.
The rust-replacements for coreutils are a good negative example.
The new programs do not reach feature-parity, added regressions, and in some cases also had security vulnerabilities.
So for battle-proved software I wouldn't say so per-se (if your goal is to replace them).
Nonetheless, if you add truly new rust-code to a new or existing codebase when it's without much of hassle with the interop it should hold.
Not necessarily. "Quality" and "Security" can be tricky subjects when it comes to a shell. Rust itself is pretty great, but its HN community is made of cringe and zealotry - don't let them dissuade you from trying the language :P
zie|3 months ago
Any GC'd language(Python, JS, Ruby, etc) gives you the same memory safety guarantees that Rust gives you. Of course GC'd languages tend to go a fair bit slower(sometimes very drastically slower) than Rust. So really the memory safety bit of Rust is that the memory safety happens at develop and compile time, instead of at runtime, like a GC language does. So you get the speed of other "systems" languages, like C, C++, etc AND memory safety.
vlovich123|3 months ago
There’s some reason to believe that given how easy it is to integrate testing into the rust code base and in general the trait and class system is also a bit higher quality and it encourage better isolation and things like const by default and not allowing API that could misuse the data structure in some unsafe way. And it has a rich ecosystem that’s easy to integrate 3p dependencies so that you’re not solving the same problem repeatedly like you tend to do in c++
So there is some reason to believe Rust does actually encourage slightly higher quality code out of developers.
Philpax|3 months ago
It is not, but the language and ecosystem are generally very well-designed and encourage you to "do the right thing," as it were. Many of the APIs you'd use in your day-to-day are designed to make it much harder to hold them wrong. On balance, outside of Haskell, it's probably the implementation language that fills me with the most confidence for any given particular piece of software.
netbioserror|3 months ago
In native-compiled languages (Nim, D, etc), the penalty for GC can be astoundingly low. With a reference counting GC, you're essentially emulating "perfect" use of C++ unique_ptr. Nim and D are very much performance-competitive with C++ in more data-oriented scenarios that don't have hard real-time constraints, and that's with D having a stop-the-world mark-and-sweep GC.
The issue then becomes compatibility with other binary interfaces, especially C and C++ libraries.
carlmr|3 months ago
Not true, you get one of the strongest and most expressive type systems out there.
One example are the mutability guarantees which are stronger than in any other language. In C++ with const you say "I'm not going to modify this". In Rust with &mut you're saying "Nobody else is going to modify this." This is 100x more powerful, because you can guarantee nobody messes with the values you borrow. That's one very common issue in efficient C++ code that is unfixable.
Sum types (enum with value) enable designing with types in a way otherwise only doable in other ML-based languages. Derive macros make it easy to use as well since you can skip the boilerplate.
Integers of different sizes need explicit casting, another common source of bugs.
Macros are evaluated as part of the AST. A lot safer than text substitution.
Further the borrow checker helps with enabling compile time checking of concurrency.
The list goes on, but nobody that has tried Rust properly can say that it only helps prevent memory safety issues. If that's your view, you just showed that you didn't even try.
adastra22|3 months ago
d6e|3 months ago
ablob|3 months ago
So for battle-proved software I wouldn't say so per-se (if your goal is to replace them).
Nonetheless, if you add truly new rust-code to a new or existing codebase when it's without much of hassle with the interop it should hold.
killme2008|3 months ago
We’ve been using Rust for about seven years now, and as long as you stay away from fancy unsafe tricks, you really can avoid most memory safety bugs.
unknown|3 months ago
[deleted]
handwarmers|3 months ago