Live data from Hacker News

Replacements for existing software written in Rust

github.com

31–40 of 229 posts

Re: Replacements for existing software written in Rust

#31
post #7

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.

There are plenty of memory-safe languages equally suitable for similar CLI tools and, arguably, easier to write than Rust.

I don't disagree - IMO 95% of what's written in Rust should have been written in OCaml years ago. But often those languages aren't used, for whatever reason. If Rust is what gets us the actual big rewrite into memory-safe languages, I'll take it.

Re: Replacements for existing software written in Rust

#32
This silly list (for the several reasons that have been repeated in most comments here) makes me want to see another list that would actually be useful:

A list of "software replacements that are considerably better[0] than most well-known counterparts"

[0] disclaimer for nitpickers: obviously not for 100% of cases, but what we could say for the "general usage". E.g. I'm sure there is someone out there that claims an obscure feature of grep is not replaceable for their workflow... but for the other 99% cases, ripgrep is fantastic.

Re: Replacements for existing software written in Rust

#33

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.

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.

Re: Replacements for existing software written in Rust

#34
post #7

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.

Which security vulnerabilities have been found and exploited in the tools listed?

Re: Replacements for existing software written in Rust

#35
post #7

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.

Which security vulnerabilities have been found and exploited in the tools listed? I mean your point is valid, broadly speaking, but those usually apply to consumer software like, what Rust was initially designed for, browsers.

Re: Replacements for existing software written in Rust

#36
post #9
post #2

He he. The name is slightly ambiguous, at least to me, I originally thought people were already rewriting Rust tools :-))

Your reading of the title is grammatically correct. "written in Rust" is a modifier, and modifiers apply to the noun that comes just before it -- in this case, "existing software". The title implies that existing software written in Rust should be replaced.

grammarly?

Re: Replacements for existing software written in Rust

#37

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.

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.

That falls under the case I mention of "tool is superior".

Re: Replacements for existing software written in Rust

#39
I know people here are a bit touchy about Rust, and writing everything in Rust. But here is one advantage I have found with Rust programs: The installation just works. Cargo, as a package manager, is just wonderful.

I have lost counts of how many times my "brew" or "pacman" failed to install something. It's much worse if it's Python; and things that work in macOS are not guaranteed to compile in Linux, and vice-versa. On the other hand, my "cargo install" almost never fails.

For that reason alone, I welcome any initiative to write something in Rust.

Post reply on HN