11–20 of 229 posts
Why? Most of these "existing software" are tried and tested tools that have stood the test of time. Why rewrite them and introduce potential bugs? Write something new!
Does anybody miss Sendmail? That had also "stood the test of time".
Am I the only one who doesn't care what a tool / software package is written in, provided it does the job? If a Rust port is superior then sure, I'll use it, but I won't use it because it was written in Rust.
Language per se isn't important, but the majority of security vulnerabilities are still caused by non-memory-safe languages. So I'd regard that as a reason not to use a given software package.
Am I the only one who doesn't care what a tool / software package is written in, provided it does the job? If a Rust port is superior then sure, I'll use it, but I won't use it because it was written in Rust.
* joy of coding
* (human) efficiency of coding
* performance of idiomatic code
* interoperability with C
* deployability
I'm totally sold on Rust. Yet: Why would I want to replace tried and tested tools with new versions just because they're written in Rust?
I burned myself on this when I was young and naive: Having just learned Haskell, I tried to use Haskell replacements for everything. It was incredibly stupid and counterproductive (the biggest real-world pain was clinging to darcs over git for a long time at the beginning of the DVCS wars – not because of darcs' arguable good features, but because it is written in Haskell; so stupid).
Earlier quoted context omitted.
Language per se isn't important, but the majority of security vulnerabilities are still caused by non-memory-safe languages. So I'd regard that as a reason not to use a given software package.
Half those applications are going to have other classes of new bugs simply because it’s new code and they’ve had less people audit the code. Plus some of those original tools were already written in safe languages like Haskell.
True. But most other classes of bug are not security bugs by default in the way that memory safety bugs are.
I get the point of wanting to use safer languages but I feel this list somewhat misses the point and looks more like some misguided worship to a single language. For example a lot of complaints that can be made about C and C++ don’t apply to Haskell yet this list parades a Rust counterpart to Shellcheck as if it’s automatically better just by the fact it’s written in Rust (frankly, I’d rather trust the more mature Sh…
Especially since one huge strength of Rust is its C interoperability, one would imagine that incrementally replacing or extending parts of the legacy tools would be a much more sound approach. But of course, the point you make does answer this:
> And a lot of those projects are just someone’s pet project, often written as a task for learning Rust, and certainly likely to have numerous new bugs that haven’t yet been found just by virtue of being a ground up rewrite.
Many of the replacements are indeed not meant to actually replace the tools. They're learning projects. That's great, but it's a bit scary that people wanna use them for anything else.
runc is written in Go, not Rust.
Earlier quoted context omitted.
Language per se isn't important, but the majority of security vulnerabilities are still caused by non-memory-safe languages. So I'd regard that as a reason not to use a given software package.
Half those applications are going to have other classes of new bugs simply because it’s new code and they’ve had less people audit the code. Plus some of those original tools were already written in safe languages like Haskell.
As for other kinds of bugs, yeah, that's inevitable, but I still prefer to have the memory safety bugs eliminated from the get go so I'd still say it's a worthy sacrifice to walk the road to safe tools one more time just for the memory safety.
So yeah, no need to rewrite tools in already memory safe languages but when it comes to C/C++ tools then yes, we need to rewrite them.
Why? Most of these "existing software" are tried and tested tools that have stood the test of time. Why rewrite them and introduce potential bugs? Write something new!
Rewriting in a memory-safe language is worth it. But it shouldn't be a religion, I completely agree on that.
Why? Most of these "existing software" are tried and tested tools that have stood the test of time. Why rewrite them and introduce potential bugs? Write something new!
Because they can be rewritten by removing legacy cruft, in a language that prevents the numerous security issues they had (and still have), and optimizing several things besides... Does anybody miss Sendmail? That had also "stood the test of time".
The idea is that language will not solve poorly designed software, but a developer that knows what he is doing like Wietse did with Postix. And Postfix stood the test of time pretty well, considering how complex it is.