Live data from Hacker News

Replacements for existing software written in Rust

github.com

71–80 of 229 posts

Re: Replacements for existing software written in Rust

#71

Earlier quoted context omitted.

...then they get the job and the library or tool goes unmaintained. Endless churn ensues. See the javascript ecosystem.

To clarify: I'm in no way opposed to experimentation, learning and weekend projects. But there current "github-centered" development culture makes it very difficult to tell if authors are invested in their FOSS projects are going to maintain them or not. As the churn keeps increasing we can end up with ecosystems collapsing. In comparison, the library maintained since 2003 by the Nebraska person is less worrying. htt…

Also, the "don't write code, just find a library that does what you want to do and plumb it in" mentality means that people approach a problem by searching Github, find these half-finished experiments, and ship them to prod.

I exaggerate, of course, but not by much

Re: Replacements for existing software written in Rust

#73

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!

OpenSSL was deemed as standing the test of time as well. Then Heartbleed happened. Rewriting in a memory-safe language is worth it. But it shouldn't be a religion, I completely agree on that.

I don't think anyone thought OpenSSL was good code even before Heartbleed. Bob Beck pointed that out in his LibreSSL talk https://youtu.be/GnBbhXBDmwU

Re: Replacements for existing software written in Rust

#74

Earlier quoted context omitted.

OpenSSL was deemed as standing the test of time as well. Then Heartbleed happened. Rewriting in a memory-safe language is worth it. But it shouldn't be a religion, I completely agree on that.

I don't think anyone thought OpenSSL was good code even before Heartbleed. Bob Beck pointed that out in his LibreSSL talk https://youtu.be/GnBbhXBDmwU

Then he's the exception, at least anecdotally in my career and life. Most C/C++ programmers I've known were ready to defend their code quality with their fists. They were in complete denial.

Re: Replacements for existing software written in Rust

#75

Earlier quoted context omitted.

You're probably not the only one. However, I will always prefer CLI tools written in C/Go/Rust/anything native because Python dependency management is a shitshow and its startup time is way too slow.

But you're bringing up a good argument for preferring a binary over a script there - portability, external dependencies, performance are important factors. I don't believe performance will be significantly different if you're comparing a C vs a Rust tool though.

ripgrep is way faster than grep (okay, it's missing some features), but grep is way older.

sd is an order of magnitude faster than sed, but it's missing some features like deleting matching lines.

You could rewrite some of those older core utils written in C to make them run concurrently...

Re: Replacements for existing software written in Rust

#76
post #20
post #11

Earlier quoted context omitted.

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".

Sendmail never stood the test of time and is pretty much abandoned now, replaced with Postfix. Guess in what language Postfix was written... 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.

Sendmail is now owend by Proofpoint and I can only assume it forms the basis of the MTAs for their gateway.

Re: Replacements for existing software written in Rust

#77
post #15
post #12

Earlier quoted context omitted.

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.

> 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. True. But most other classes of bug are not security bugs by default in the way that memory safety bugs are.

That’s not true at all. 2 of the 3 biggest security vulnerabilities I’ve had to deal with in my career were completely unrelated and wouldn’t have been prevented had software been written in Rust instead.

Also half the software mentioned in that gist should never be used in security-focused applications anyway (if your depending on ‘cat’ or ‘awk’ to be bug free for your application to be hardened then you’re already doing it wrong)

Re: Replacements for existing software written in Rust

#78

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!

OpenSSL was deemed as standing the test of time as well. Then Heartbleed happened. Rewriting in a memory-safe language is worth it. But it shouldn't be a religion, I completely agree on that.

Heartbleed happen because the open source software used by everyone were left getting dust, with low maintenance and despite its popularity, nobody was paying or donating nothing to keep the project going.

Even if Rust was invented in the 80's, and such a project was in it, the same could happen in one of those unsafe{} blocks a Rust project like this might need to use (and we are forgetting all the ordinary bugs even in the safe portions of the code).

Sure, being in C might be a part of the problem, and this is a good space for tools like Rust to occupy more space, but there's a bigger picture or else Linux would be breaking all the time, and its a solid, big and complex piece of software that works pretty well because there's a lot of economical incentives to keep it going.

Re: Replacements for existing software written in Rust

#79

Earlier quoted context omitted.

As a fan of the language I also don't get this. I mean I welcome wider adoption of Rust for various reasons, but this whole "it's written in Rust!" checkbox filling doesn't have any connection to what matters in reality. If you're rewriting something anyway, or creating something new then Rust should be considered. But a lot of the value of old software is not the set of features listed in the Readme. Not every area…

Would you feel better about this is if the badge was "Written in a memory-safe language"?

Is a memory-safe language a safe language ? Is it not possible to exploit rust ?

Re: Replacements for existing software written in Rust

#80
The expressions against hype and the admonitions regarding unmaintained hobbyist projects on GitHub are okay, but personally I'm happy to learn about the tools on this list, and I'm grateful to be able to study reimplementing something we know (coreutils) in a language we ought to know better (Rust).

This doesn't automatically mean we would deploy this stuff when going to Mars; so I don't think some of the sentiments expressed here are the fault of the enthusiastic reimplementers.

(Looking forward to your reimplementations of coreutils in R5RS Scheme.)

Post reply on HN