See https://news.ycombinator.com/item?id=24133128 for a recent, very relevant discussion on that topic with multiple examples and a good rationale.
Rust provide you tools to avoid many security issues. But that does not mean everything that hasn't been written in Rust is broken by default.
You still have "unsafe" in Rust, so is it broken by default and design and we should throw away the language ? Obviously not!
I haven't seen anyone arguing against Python or Java in a Rust thread. Memory-managed languages are already at the memory safety levels comparable to Rust's borrow checker.
More specifically, I hope, C++. I like to think of asm, C, and Rust as a trio. C isn't "better" than asm; it just doesn't make sense to use asm when C does the job. And it doesn't make sense to use C when Rust does the job.
C++ is where, in almost all scenarios, I draw the line and say, this would be probably be better if new code is written in Rust.
> And it doesn't make sense to use C when Rust does the job.
There are few jobs left where C can do it and Rust can't, those jobs are generally "well there exists a C compiler for this architecture and not a rust/llvm backend". Rust is generally just as capable as C is at writing low level code. If you're willing to put up with translating macros by hand (or using wrapper functions), it's even capable of integrating with existing C code bases.
Lots of people still prefer C over Rust in various situations where you could use Rust, so I don't think it's a generally accepted fact that "it doesn't make sense to use C when Rust does the job".
For more ordinary software though, doesn't Rust make more sense? Its approach to memory management for instance, with a borrower-checker, seems much nicer than what Ada has to offer.
Disclaimer: I know neither language very well.
No language has traction, until it does.
It would be fair to point out though that Ada has had decades to catch on and replace C, but it hasn't done so, except in certain narrow areas of highly critical embedded software development in aviation and military applications. My understanding is that it's not easy to work with for 'general purpose' work (command-line applications on GNU/Linux), as it lacks mature bindings.
I think it's fair to say Ada failed to truly embrace Free and Open Source software. A pity, in my opinion.
Are the higher assurance-levels of SPARK going to remain unavailable to FOSS developers, as they apparently are now? [1]
[0] https://groups.google.com/forum/#!topic/comp.lang.ada/M3yS4S...
Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. In addition, the Lisp compilers are written in Lisp itself, not in C, which further decreases the attack vector.
Also, the currently-in-progress SICL project intends to do away with C completely, even for its garbage collection and OS-interfacing parts.
Totals grouped by language (dominant language first):
lisp: 336793 (84.60%)
asm: 30410 (7.64%)
ansic: 29862 (7.50%)
sh: 718 (0.18%)
objc: 299 (0.08%)
java: 7 (0.00%)
Yeah, right.
In Lisp, the programmer never frees memory themselves, so use-after-free and double-free are not triggerable by the user. Bound checks for all array types are in effect, so overflows are impossible. Strong typing and a lack of casting prevent type confusion.
Do you have any arguments other than the unsubstantial "yeah, right"?
Rust not only gives you safety and correctness, but gives you often speed as a bonus over C. There is a real benefit towards rewriting everything written in C in a language/tool system like Rust.
There is still a place for other languages, especially ones that use a garbage collector. Rust would make that garbage collector a lot safer.
Rewriting is easier than doing original work. If you manage to get people to use "your" new Rust project, you get a huge payoff for comparatively little work with lots of plagiarizing.
Your argument is quite flawed.
At this point, it's just falling for the hype.
The same thing happenned with go, es6, etc...
"X is better than Y because it is written in Z" is not a valid argument.
A kernel in Rust? Yes please. A browser in rust? Can't wait. A fork of openssl in rust? Yes yes yes. A cli tool? Why? Is it really necessary?
And yes it is a genuine question, not some random rant.
> A fork of openssl in rust? Yes yes yes.
Projects done for fun are not "marketed" as "a replacement for X"
The only reason to use Rust is if you need the performance. But often, that's only an issue in your "inner loops", so you could write the rest of your code in a more suitable language.
Since in most cases these performance critical parts are only small in terms of lines of code, and hence easily verifiable by hand, you could even write them in C and still not have security issues.
Therefore, I think Rust serves only a very specific need, and isn't nearly as universally "the right tool" as everyone seems to believe.
They do have a nice packaging system, though.
Totals grouped by language (dominant language first):
python: 578880 (54.33%)
ansic: 475310 (44.61%)
sh: 4073 (0.38%)
cpp: 3847 (0.36%)
asm: 1486 (0.14%)
objc: 761 (0.07%)
lisp: 502 (0.05%)
pascal: 353 (0.03%)
xml: 308 (0.03%)
csh: 21 (0.00%)
OK, we can drop the HN comments. Since Stefan Hajnoczi is a substantial QEMU contributor, how would you respond to the arguments linked in http://blog.vmsplice.net/2020/08/why-qemu-should-move-from-c...?
Safe Rust is automatically immune to lots of these issues. Unsafe Rust isn't, but all of C is unsafe (unless you're using a safety-enforcing linter that only gives you access to a subset of the language).