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 Shellcheck).<p>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.<p>As I said, I’m fully in favour of using newer and safer languages but we need to be careful not to get carried away with thinking anything new is better simply because it’s new.
Wow, a <i>lot</i> of hate for this list, but I'll unpick something that is slightly below the surface here:<p>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.<p>However, what I tend to find with the new rust CLI tools is that they bring with them modern design sensibilities. They can use better conventions, better defaults, assume things like colour terminal emulators (or fallback to non-colour if not outputting to a terminal).<p>The experience of using them is often much different to using the old GNU versions made in the 80s which reimplement tools made in the 60s and 70s.<p>I'm not saying all the other criticisms in this thread aren't valid, but I think it's worth highlighting the positives of the tools mentioned in a list like this rather than just throwing negativity on it.
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.
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.<p>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.<p>For that reason alone, I welcome any initiative to write something in Rust.
These Rust replacements are unique in the way that most of them vastly improved on the original. I still don't quite understand what about Rust made that happen. They could have been easily written in, say, Nim years before Rust existed.
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:<p>A list of "<i>software replacements that are considerably better[0] than most well-known counterparts</i>"<p>[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 <i>grep</i> is not replaceable for their workflow... but for the other 99% cases, <i>ripgrep</i> is fantastic.
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!
I compiled a list of modern replacements for unix commands [0]. While many of them are written in Rust, there are C, Go, and Python programs on that list as well, because I feel the point is not what language the tool is written in, as long as it solves a problem or is an improvement over existing tooling in some way. Not a knock against this list, I just think it is better to list <i>all</i> tools that may be useful to people, rather than excluding some simply because of the creator's choice of language.<p>[0]: <a href="https://github.com/ibraheemdev/modern-unix" rel="nofollow">https://github.com/ibraheemdev/modern-unix</a>
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).<p>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.<p>(Looking forward to your reimplementations of coreutils in R5RS Scheme.)
There's also 'Conduit', a Matrix server written in Rust. It's alpha currently.<p><a href="https://matrix.org/docs/projects/server/conduit" rel="nofollow">https://matrix.org/docs/projects/server/conduit</a>
I might not be familiar enough with the original tools, nor the Rust ecosystem, so excuse me if this is misinformed. But the trend seems to be that the Rust tooling is a lot richer than their original counterparts.<p>Is this accurate? And if so, is it super easy to write rich CLIs, with tabulated, coloured, interactive TUIs in Rust? Are their some common, widely used libraries driving this trend?
The main thing that interests me in Rust and Go rewrites of common tools (bat, ripgrep, broot, etc.) is that they use their newness as an opportunity to have nicer output and simpler CLIs or nice TUIs. It's not really about the language for me.
Perhaps someone already mentioned it here, but GraalVM lets you interop between Java and anything LLVM, and therefore Rust, without the JVM startup cost, with breakpoints across languages, even (as I understand it). Compile time is long, though.<p>borkdude has been releasing for some very cool stuff using this stuff. Here's a Clojure/Rust combo:<p><a href="https://github.com/borkdude/clojure-rust-graalvm" rel="nofollow">https://github.com/borkdude/clojure-rust-graalvm</a>
I love the idea of having more user land tools but are those tools POSIX compliant? If not those aren't replacements.<p>Now if that's the case that's also cool. I also love new ways of doing old things and we might sooner or later have something that looks like Redox on Linux/BSD kernels.
Good to have a reference for such tools in one place. Added a PR for frawk [0] (awk alternative, WIP, haven't tried it yet)<p>[0] <a href="https://github.com/ezrosent/frawk" rel="nofollow">https://github.com/ezrosent/frawk</a>
If were talking about libs and APIs then game on, but otherwise, I actually don't care what <i>language</i> a tool is written in. I care how good the tool is.<p>No, I don't think you will find a high correlation between language and tool quality.
Did anyone else parse the title as “replacements for existing software that is written in Rust”? I thought, wow, Rust is already passé, what’s the new hotness?
I (mostly) love Rust, but the fact is that it makes lots of easy things hard. Most software should be written in a GC language. Even Java or Go are a better choice for most “backend” development, despite the fact that from a PL design standpoint they’re vastly inferior to Rust.