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.
Replacements for existing software written in Rust
31–40 of 229 posts
Re: Replacements for existing software written in Rust
#32A 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
#33Am 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.
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
#34Am 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.
Re: Replacements for existing software written in Rust
#35Am 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.
Re: Replacements for existing software written in Rust
#36He 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.
Re: Replacements for existing software written in Rust
#37Am 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.
Re: Replacements for existing software written in Rust
#38Re: Replacements for existing software written in Rust
#39I 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.