Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Replacements for existing software written in Rust

github.com

Post reply on HN
Print view View original

101–110 of 229 posts

Re: Replacements for existing software written in Rust

#101

Post by pdimitar »

afarrell wrote: post #85
pdimitar wrote: post #68

Earlier quoted context omitted.

> Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. Absolutely. It's just that statistically the memory safety bugs have been the dominant percent of all the bugs, so rewriting core tools in a memory-safe language does make sense.

Indeed. Time & attention are limited resources. By eliminating the dominant class of bugs you have more time and attention for more subtle bugs.

> Time & attention are limited resources. By eliminating the dominant class of bugs you have more time and attention for more subtle bugs.

Beautifully articulated.

Re: Replacements for existing software written in Rust

#102

Post by singhrac »

laumars wrote: post #8

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…

I mostly agree with this sentiment but I think it's not that necessary to point out. Yes, some of these are abandonware but many are written by the same set of strong Rust programmers. I think you'd be hard pressed to argue that ripgrep or fd is not a valuable contribution to the OSS ecosystem.

The more interesting question is - why is that? Sure, Rust is memory safe, but I suspect the real reason people built high quality software in Rust is because cargo is good and because minimizing copies is part of the culture around the language. This means that libraries are cheap to use, and as a result programming feels productive, because you don't have a reason to reinvent the wheel (see arrays in C, or various Boost libraries that have been moved into stdlib C++). For example, compare the cost of Python's click to Rust's clap. Or look at serde.

I find it more interesting to ask the question "why do people spend so much hobby time writing interesting programs in Rust?".

Re: Replacements for existing software written in Rust

#103

Post by kevinmgranger »

laumars wrote: post #8

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…

The page claims they're awesome, it doesn't claim they're better.

Re: Replacements for existing software written in Rust

#104

Post by smitherfield »

singhrac wrote: post #102
laumars wrote: post #8

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…

I mostly agree with this sentiment but I think it's not that necessary to point out. Yes, some of these are abandonware but many are written by the same set of strong Rust programmers. I think you'd be hard pressed to argue that ripgrep or fd is not a valuable contribution to the OSS ecosystem. The more interesting question is - why is that? Sure, Rust is memory safe, but I suspect the real reason people built high q…

> because you don't have a reason to reinvent the wheel [in Rust]

This is a somewhat comical statement in a thread about "Rewrite it in Rust."

Re: Replacements for existing software written in Rust

#105

Post by dlivingston »

Zhyl wrote: post #52

Wow, a lot of hate for this list, but I'll unpick something that is slightly below the surface here: We are currently seeing a bit of a command line renaissance. The justification for this is a 'rust rewrite', but as many have pointed out, just because something is in such-and-such a language doesn't make it good. However, what I tend to find with the new rust CLI tools is that they bring with them modern design sens…

My biggest problem with this list is that when I write shell scripts, I usually intend for them to be used by colleagues or others.

Having non-POSIX applications used in these scripts means that portability is limited.

Yes, I know that with aliases I can override this, but I’m not convinced yet that straying from “this will work on everyone’s machine” to “set an alias for X, and X will probably be an appropriate stand-in for Y” is good enough to guarantee zero-issue compatibility.

Re: Replacements for existing software written in Rust

#106

Post by a-nikolaev »

benibela wrote: post #90
laumars wrote: post #8

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…

I have been rewriting things in Pascal for years, because it is much safer than C, and no one cares about that :(

That's awesome though!

Re: Replacements for existing software written in Rust

#107

Post by pdimitar »

oscargrouch wrote: post #78
pdimitar wrote: post #19

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.

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 eve…

> with low maintenance and despite its popularity, nobody was paying or donating nothing to keep the project going.*

There probably is a Wikipedia page describing this phenomena but I'll settle for calling it "the commodity effect": when something is very widely used then everybody assumes it has been improved to perfection and that it has no flaws (this is not exclusive to software engineering, it happens in many areas of life).

> the same could happen in one of those unsafe{} blocks a Rust project like this might need to use

Sure but they are much easier to search for and audit (like with e.g. `cargo-geiger`). That by itself is a win. Whereas C/C++ needs a special class of linters and scanners, a good chunk of which are paid (a deal-breaker for many software devs not because they're poor but because they don't want to pay for them out of their pocket, and their employer is blind to see the added value and buy those tools for them).

> and we are forgetting all the ordinary bugs even in the safe portions of the code

Only people with agenda forget about those. I worked with Rust in 3 companies in total so far and I've only seen serious, diligent, hard-working devs with attention to detail and a slight case of efficiency mania. :) And they were very mindful of potential bugs and we wrote a lot of tests of different kinds like acceptance/integration, unit, property, and probably others.

No normal smart developer forgets that memory safety bugs are just one class of all the bugs. Turns out however that those are the most widespread bugs in general so IMO it is sensible to use a language that eliminates them by the mere virtue of compiling your program -- and not using unsafe{} in certain ways.

As another poster said, time and attention are limited resources. By removing memory safety bugs from the picture our brains are now free to pay proper attention to the more subtle bugs.

Re: Replacements for existing software written in Rust

#108

Post by pdimitar »

oscargrouch wrote: post #78
pdimitar wrote: post #19

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.

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 eve…

Answering to another point separately because my other comment grew large enough already:

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

It is solid... as far as we know. Truth is, nobody is fuzzing the Linux kernel 24/7 except maybe the worst possible actors like national intelligence agencies or malevolent hacking groups -- and they of course would never share and help fix a zero-day because it can help them make money by exfiltrating sensitive information and/or breaking in protected networks.

Don't get me wrong, I admire the Linux kernel devs. They are a standing tribute to all ideas of free and open source and open project management. But Linus himself said security isn't the first priority of the kernel which already means that certain potential problems in the code are being overlooked in favor of speed and stability.

(There was a story some weeks ago on HN showing that there was a pretty nasty exploitable bug in the Linux kernel but I lost the link.)

Re: Replacements for existing software written in Rust

#109

Post by seoaeu »

dlivingston wrote: post #105
Zhyl wrote: post #52

Wow, a lot of hate for this list, but I'll unpick something that is slightly below the surface here: We are currently seeing a bit of a command line renaissance. The justification for this is a 'rust rewrite', but as many have pointed out, just because something is in such-and-such a language doesn't make it good. However, what I tend to find with the new rust CLI tools is that they bring with them modern design sens…

My biggest problem with this list is that when I write shell scripts, I usually intend for them to be used by colleagues or others. Having non-POSIX applications used in these scripts means that portability is limited. Yes, I know that with aliases I can override this, but I’m not convinced yet that straying from “this will work on everyone’s machine” to “set an alias for X, and X will probably be an appropriate stan…

Honestly this just highlights a weakness of shell scripts. The idea that you cannot use any new dependencies (or even upgraded versions of the current dependencies!) would be unthinkable in most other settings.

Re: Replacements for existing software written in Rust

#110

Post by nicoburns »

blacktriangle wrote: post #95
nicoburns wrote: post #93

Earlier quoted context omitted.

I get it pretty often too. Having said that, I haven't typically had much to show and I've usually been offered the job anyway so I'm not sure it's typically given that much weight.

I've asked that question. I use it as a way to offer an alternative demonstration of work to developers who are early in their careers. It's not about seeing the code as much as it is wanting to see that a person has taken software through the full lifecycle. I'd rather see an app in an App Store or a live site on the web, or even just talk about an in-house project that they've managed over a period of years.

That makes a lot of sense. Most of my github projects are from prior to my first job, which I was quite proud of at the time, but are somewhat less demonstrative of my skill level now over 10 years later.
Post reply on HN