20 ms·

Replacements for existing software written in Rust

170 points by prabir 5y ago

oblio 5y ago
He he. The name is slightly ambiguous, at least to me, I originally thought people were already rewriting Rust tools :-))
- Dirak 5y ago
  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.
  - hnedeotes 5y ago
    grammarly?
asicsp 5y ago
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) [0] https://github.com/ezrosent/frawk https://github.com/ezrosent/frawk
bruce343434 5y ago
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!
- Jataman606 5y ago
  Most of this are not actual rewrites, but "write-a-news", so they are not drop in replacements. Like ripgrep for example: it servers the same task, but is in some ways improvement over "tried and tested" grep.
- coldtea 5y ago
  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".
  - dig1 5y ago
    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.
    - coldtea 5y ago
      >The idea is that language will not solve poorly designed software Another idea is that a software can have a great design but still be full of security holes. C allows for that. If we leave it to the "adequately advanced programmer" to avoid those, we're doing it wrong - with plenty of historical examples to prove this.
      - afarrell 5y ago
        Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. The only thing that will actually prevent security holes is attentive software engineers deliberately choosing to learn tools and practice habits to avoid security holes by design. The professional judgement of a lot of those engineers is leading them to choose to learn rust right now.
        pdimitar 5y ago
        > 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.
- pdimitar 5y ago
  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.
  - protomyth 5y ago
    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 https://youtu.be/GnBbhXBDmwU
    - pdimitar 5y ago
      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.
  - oscargrouch 5y ago
    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.
    - pdimitar 5y ago
      > 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.
- beforeolives 5y ago
  Hobby projects? I wonder how many of these projects match this pattern: 1. Rust is new and cool and I want to be a Rust developer. 2. There are almost no Rust jobs out there. 3. I don't have original ideas or any actual use cases for this language. 4. So I will rewrite something that already exists in it.
- EamonnMR 5y ago
  Writing something new in rust is harder than rewriting because you need to think a lot about your memory model up front. In other languages you can leak all the memory you want and then (maybe) figure enough of it out when you've already shipped/already deployed. In Rust you need to do the up front work, so instead of releasing a leaky program, you don't release a program at all. If there is an existing program you can make assumptions more readily.
- ironmagma 5y ago
  As many say, open source is about choice. There are no choices if there’s only one of each thing.
de_keyboard 5y ago
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.
- techn00 5y ago
  Indeed, use the right tool for the job
- lmm 5y ago
  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.
  - laumars 5y ago
    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.
    - lmm 5y ago
      > 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.
      - laumars 5y ago
        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)
laumars 5y ago
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). 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. 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.
- Zababa 5y ago
  I don't think that list misses the point, a lot of what's in here is actually a better/more modern alternative. Starting with "An experimental container runtime" isn't a great idea, but bat, tokei, dust, fd, skim, exa, fnm, hyperfine, tealdeer and just are all serious projects. I do think the list could be curated a bit harder (and ripgrep should be added, fortunately there's already a pull request). > 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. I'd say 6 of them are not as serious as the others, but even them have 5 contributors or more. Is this what you mean by "a lot", 6 out of 34 (at the time of writing this) ?
  - laumars 5y ago
    “A lot” is certainly a subjective term and thus open to interpretation. One might argue that the entirety of the collection isn’t “a lot” since it only amounts to 34. Others might argue that 17% is “a lot” as it’s that means near enough 1 in 5 projects isn’t mature and that’s a pretty poor signal to noise ratio. If the repo advertised itself as a curated list of interesting Rust alternatives to standard tools then I probably wouldn’t have commented. But it said “replacements” and that suggests a higher level of maturity and community support.
29athrowaway 5y ago
runc is written in Go, not Rust.
- Hasnep 5y ago
  runc is listed as the original program and youki is the Rust rewrite.
faichai 5y ago
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. 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?
- 13415 5y ago
  Nothing in Rust is super easy, it's an overengineered pile of crap and in 20 years from now people will be cursing at it daily.
  - cestith 5y ago
    If people are still cursing at your programming language 20 or 30 years later, you've done at least a decent job of things. Do you hear many people complaining about Eiffel, Dylan, or Boo lately?
- afarrell 5y ago
  > Are their some common, widely used libraries driving this trend. The rust community leadership made a strategic decision to pick 4 areas to suggest focus on. CLIs was one of them. (Scroll to “build it in rust” on https://www.rust-lang.org/ https://www.rust-lang.org/) I think this choice and many others by the rust leadership merit a case study in community technical leadership. Or at least a blog post by the author of https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teach-the-oss-community-about-marketing/ https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-tea...
- jll29 5y ago
  Some are supersets and many are experimental subsets. It's early days, similar to when everyone wrote their own editor in TurboPascal. Regarding TUIs, have a look at thes screenshots and example codebases for these libraries: https://crates.io/crates/tui https://crates.io/crates/tui https://crates.io/crates/spotify-tui https://crates.io/crates/spotify-tui https://crates.io/crates/cursive https://crates.io/crates/cursive TUIs are in many ways more ergonomical, in particular they make experienced users more productive and they can help reduce RSI by limiting the need to move the mouse.
ulzeraj 5y ago
I love the idea of having more user land tools but are those tools POSIX compliant? If not those aren't replacements. 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.
j1elo 5y ago
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.
rgmark 5y ago
What are the chances they did clean room implementations for all of these?
- gilnaa 5y ago
  a tool doesn't have to be a clean room implementation to be useful
csomar 5y ago
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.
- ritchiea 5y ago
  Wow I think in 10+ years, I've only had 1 or 2 cases of brew failing to install something. It's a piece of software I've been consistently impressed with over the years. I wonder why our experiences differ so much.
  - csomar 5y ago
    It's been a while since I did any coding on macOS but if I remember accurately, I think it didn't play nice with macports (which I needed for some other packages).
  - jcelerier 5y ago
    Damn, for me it breaks every couple months
- Mauricebranagh 5y ago
  Probably a good reason not to use MAC as development platform. The last straw for me was being unable to do something simple like install vey common Perl packages natively via CPAN.
- twa10 5y ago
  Project specific centralized package repositories have the danger of being political (see npm and others). There already is a CoC here that can be used against wrongthink or people you don't like: https://crates.io/policies https://crates.io/policies These days, I prefer Linux distributions or BSD ports, though Homebrew seems to be pretty casual as well.
throwaway77112 5y ago
There's also 'Conduit', a Matrix server written in Rust. It's alpha currently. https://matrix.org/docs/projects/server/conduit https://matrix.org/docs/projects/server/conduit
Zhyl 5y ago
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 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). 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. 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.
- pdimitar 5y ago
  Agreed, plus some of them replace Python CLIs which are awfully slow to start (400 to 1500ms in my experience). Having those start in 3ms is a huge win in terms of ergonomics.
- dlivingston 5y ago
  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.
  - seoaeu 5y ago
    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.
  - Zhyl 5y ago
    Absolutely, and I think this raises the question of "in what sense are these 'replacements' for existing software?". If we see them as "immediate drop-in replacements" then the value of them must be that they're identical in every way and the value in them would be in the reduced maintenance overhead for the developers, with maybe a small performance boost if we're lucky. This would be fine, but it's not something that we'd notice if our distro went from using C `grep` to using a Rust rewrite of `grep`. We certainly wouldn't need a list telling us what replacements are available. However, if we see these as spiritual successors, ones that perform the same function but aren't intended to be aliased to be precisely the same thing, then it makes a lot more sense. We're not looking for backwards compatibility, portability or identical feature sets. We're instead being offered a smorgasbord of options on what ideas we want to embrace and which ones we would want to leave behind. If ripgrep is better in all use cases than grep, then eventually ripgrep will be the one being used in the scripts organically. We shouldn't be dismissing ripgrep out of hand just because a colleague won't have it on their system. Or, at the very least, we should be noting the good points while also noting that we won't be using the tools ourselves for portability reasons.
jll29 5y ago
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.)
pxc 5y ago
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.
darthrupert 5y ago
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.
- ibraheemdev 5y ago
  Systems programmers got really excited :) I don't know much about Nim but I don't think it, or Go, etc. are aimed as low-level as Rust is. Rust is pretty unique in being as low-level as C, yet providing safety and higher level abstractions.
  - darthrupert 5y ago
    Nim is aimed at pretty much the same level as Go, I would say. Only with more modern abstractions. And currently (with Nim 1.4 and its memory management), it's moving towards Rust's field. Their performance has always been in the same space, especially regarding cmdline tools, where latency is more important than most other tools.
    - cb321 5y ago
      Nim has very easy ways to get full C performance in pure Nim with a trivial FFI to just call C and is both higher level than Go and lower level at the same time because of that. Simple analogies often fail to describe. :-( { This is not intended as a dig/criticism but note on communication limits - you should just learn more about Nim at https://nim-lang.org/ https://nim-lang.org/ }
      - deleted 5y ago
        [deleted]
- GuB-42 5y ago
  Remaking traditional UNIX tools is a common exercise when learning system programming. And because Rust is quite trendy nowadays, I guess a lot of people wanted to try it out, and in some cases, that exercise turned into a viable product. Nim never got the same popularity.
deleted 5y ago
[deleted]
deepsun 5y ago
How about Busybox?
deeviant 5y ago
If were talking about libs and APIs then game on, but otherwise, I actually don't care what language a tool is written in. I care how good the tool is. No, I don't think you will find a high correlation between language and tool quality.
NextHendrix 5y ago
If rewriting in a safe language is the main driver why not rewrite everything in Ada instead of Rust?
- Narishma 5y ago
  You'd have to ask Ada programmers.
ibraheemdev 5y ago
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 all tools that may be useful to people, rather than excluding some simply because of the creator's choice of language. [0]: https://github.com/ibraheemdev/modern-unix https://github.com/ibraheemdev/modern-unix
senderista 5y ago
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?
senderista 5y ago
Would you like to replace a C program written by djb with a Rust program written by Uncle Bob?
- geodel 5y ago
  Ah Uncle Bob,the philosopher of programing methodologies. I'd imagine writing any program beyond hello world with 100% test coverage would be beneath him.
senderista 5y ago
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.
- justwalt 5y ago
  Why do you think that most modern software should be written in a GC language?
  - sweeneyrod 5y ago
    Would you consider using a non-GC language that isn't Rust outside the various domains where C/C++ is the only realistic (non-Rust) choice?
    - senderista 5y ago
      Deterministic memory deallocation makes it harder to reason about not just “easy” code, but also linked structures and lock-free algorithms (actually it is a substantial implementation obstacle for the latter). It must offset these costs by providing predictable latency or low memory footprint. Most applications don’t require either.
the-alchemist 5y ago
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. borkdude has been releasing for some very cool stuff using this stuff. Here's a Clojure/Rust combo: https://github.com/borkdude/clojure-rust-graalvm https://github.com/borkdude/clojure-rust-graalvm
dividedbyzero 5y ago
Still trying to get into both Go and Rust – is there something about Rust that makes it a better choice for such CLI utilities than Go?

170 points by prabir 5y ago

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

Dirak 5y ago
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.
- hnedeotes 5y ago
  grammarly?

asicsp 5y ago

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) [0] https://github.com/ezrosent/frawk https://github.com/ezrosent/frawk

bruce343434 5y ago

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!

Jataman606 5y ago
Most of this are not actual rewrites, but "write-a-news", so they are not drop in replacements. Like ripgrep for example: it servers the same task, but is in some ways improvement over "tried and tested" grep.
coldtea 5y ago
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".
- dig1 5y ago
  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.
  - coldtea 5y ago
    >The idea is that language will not solve poorly designed software Another idea is that a software can have a great design but still be full of security holes. C allows for that. If we leave it to the "adequately advanced programmer" to avoid those, we're doing it wrong - with plenty of historical examples to prove this.
    - afarrell 5y ago
      Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. The only thing that will actually prevent security holes is attentive software engineers deliberately choosing to learn tools and practice habits to avoid security holes by design. The professional judgement of a lot of those engineers is leading them to choose to learn rust right now.
      - pdimitar 5y ago
        > 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.
pdimitar 5y ago
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.
- protomyth 5y ago
  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 https://youtu.be/GnBbhXBDmwU
  - pdimitar 5y ago
    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.
- oscargrouch 5y ago
  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.
  - pdimitar 5y ago
    > 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.
beforeolives 5y ago
Hobby projects? I wonder how many of these projects match this pattern: 1. Rust is new and cool and I want to be a Rust developer. 2. There are almost no Rust jobs out there. 3. I don't have original ideas or any actual use cases for this language. 4. So I will rewrite something that already exists in it.
EamonnMR 5y ago
Writing something new in rust is harder than rewriting because you need to think a lot about your memory model up front. In other languages you can leak all the memory you want and then (maybe) figure enough of it out when you've already shipped/already deployed. In Rust you need to do the up front work, so instead of releasing a leaky program, you don't release a program at all. If there is an existing program you can make assumptions more readily.
ironmagma 5y ago
As many say, open source is about choice. There are no choices if there’s only one of each thing.

de_keyboard 5y ago

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.

techn00 5y ago
Indeed, use the right tool for the job
lmm 5y ago
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.
- laumars 5y ago
  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.
  - lmm 5y ago
    > 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.
    - laumars 5y ago
      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)

laumars 5y ago

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

Zababa 5y ago
I don't think that list misses the point, a lot of what's in here is actually a better/more modern alternative. Starting with "An experimental container runtime" isn't a great idea, but bat, tokei, dust, fd, skim, exa, fnm, hyperfine, tealdeer and just are all serious projects. I do think the list could be curated a bit harder (and ripgrep should be added, fortunately there's already a pull request). > 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. I'd say 6 of them are not as serious as the others, but even them have 5 contributors or more. Is this what you mean by "a lot", 6 out of 34 (at the time of writing this) ?
- laumars 5y ago
  “A lot” is certainly a subjective term and thus open to interpretation. One might argue that the entirety of the collection isn’t “a lot” since it only amounts to 34. Others might argue that 17% is “a lot” as it’s that means near enough 1 in 5 projects isn’t mature and that’s a pretty poor signal to noise ratio. If the repo advertised itself as a curated list of interesting Rust alternatives to standard tools then I probably wouldn’t have commented. But it said “replacements” and that suggests a higher level of maturity and community support.

29athrowaway 5y ago

runc is written in Go, not Rust.

Hasnep 5y ago
runc is listed as the original program and youki is the Rust rewrite.

faichai 5y ago

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

13415 5y ago
Nothing in Rust is super easy, it's an overengineered pile of crap and in 20 years from now people will be cursing at it daily.
- cestith 5y ago
  If people are still cursing at your programming language 20 or 30 years later, you've done at least a decent job of things. Do you hear many people complaining about Eiffel, Dylan, or Boo lately?
afarrell 5y ago
> Are their some common, widely used libraries driving this trend. The rust community leadership made a strategic decision to pick 4 areas to suggest focus on. CLIs was one of them. (Scroll to “build it in rust” on https://www.rust-lang.org/ https://www.rust-lang.org/) I think this choice and many others by the rust leadership merit a case study in community technical leadership. Or at least a blog post by the author of https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-teach-the-oss-community-about-marketing/ https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-tea...
jll29 5y ago
Some are supersets and many are experimental subsets. It's early days, similar to when everyone wrote their own editor in TurboPascal. Regarding TUIs, have a look at thes screenshots and example codebases for these libraries: https://crates.io/crates/tui https://crates.io/crates/tui https://crates.io/crates/spotify-tui https://crates.io/crates/spotify-tui https://crates.io/crates/cursive https://crates.io/crates/cursive TUIs are in many ways more ergonomical, in particular they make experienced users more productive and they can help reduce RSI by limiting the need to move the mouse.

ulzeraj 5y ago

I love the idea of having more user land tools but are those tools POSIX compliant? If not those aren't replacements. 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.

j1elo 5y ago

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.

rgmark 5y ago

What are the chances they did clean room implementations for all of these?

gilnaa 5y ago
a tool doesn't have to be a clean room implementation to be useful

csomar 5y ago

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.

ritchiea 5y ago
Wow I think in 10+ years, I've only had 1 or 2 cases of brew failing to install something. It's a piece of software I've been consistently impressed with over the years. I wonder why our experiences differ so much.
- csomar 5y ago
  It's been a while since I did any coding on macOS but if I remember accurately, I think it didn't play nice with macports (which I needed for some other packages).
- jcelerier 5y ago
  Damn, for me it breaks every couple months
Mauricebranagh 5y ago
Probably a good reason not to use MAC as development platform. The last straw for me was being unable to do something simple like install vey common Perl packages natively via CPAN.
twa10 5y ago
Project specific centralized package repositories have the danger of being political (see npm and others). There already is a CoC here that can be used against wrongthink or people you don't like: https://crates.io/policies https://crates.io/policies These days, I prefer Linux distributions or BSD ports, though Homebrew seems to be pretty casual as well.

throwaway77112 5y ago

There's also 'Conduit', a Matrix server written in Rust. It's alpha currently. https://matrix.org/docs/projects/server/conduit https://matrix.org/docs/projects/server/conduit

Zhyl 5y ago

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

pdimitar 5y ago
Agreed, plus some of them replace Python CLIs which are awfully slow to start (400 to 1500ms in my experience). Having those start in 3ms is a huge win in terms of ergonomics.
dlivingston 5y ago
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.
- seoaeu 5y ago
  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.
- Zhyl 5y ago
  Absolutely, and I think this raises the question of "in what sense are these 'replacements' for existing software?". If we see them as "immediate drop-in replacements" then the value of them must be that they're identical in every way and the value in them would be in the reduced maintenance overhead for the developers, with maybe a small performance boost if we're lucky. This would be fine, but it's not something that we'd notice if our distro went from using C `grep` to using a Rust rewrite of `grep`. We certainly wouldn't need a list telling us what replacements are available. However, if we see these as spiritual successors, ones that perform the same function but aren't intended to be aliased to be precisely the same thing, then it makes a lot more sense. We're not looking for backwards compatibility, portability or identical feature sets. We're instead being offered a smorgasbord of options on what ideas we want to embrace and which ones we would want to leave behind. If ripgrep is better in all use cases than grep, then eventually ripgrep will be the one being used in the scripts organically. We shouldn't be dismissing ripgrep out of hand just because a colleague won't have it on their system. Or, at the very least, we should be noting the good points while also noting that we won't be using the tools ourselves for portability reasons.

jll29 5y ago

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

pxc 5y ago

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.

darthrupert 5y ago

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.

ibraheemdev 5y ago
Systems programmers got really excited :) I don't know much about Nim but I don't think it, or Go, etc. are aimed as low-level as Rust is. Rust is pretty unique in being as low-level as C, yet providing safety and higher level abstractions.
- darthrupert 5y ago
  Nim is aimed at pretty much the same level as Go, I would say. Only with more modern abstractions. And currently (with Nim 1.4 and its memory management), it's moving towards Rust's field. Their performance has always been in the same space, especially regarding cmdline tools, where latency is more important than most other tools.
  - cb321 5y ago
    Nim has very easy ways to get full C performance in pure Nim with a trivial FFI to just call C and is both higher level than Go and lower level at the same time because of that. Simple analogies often fail to describe. :-( { This is not intended as a dig/criticism but note on communication limits - you should just learn more about Nim at https://nim-lang.org/ https://nim-lang.org/ }
    - deleted 5y ago
      [deleted]
GuB-42 5y ago
Remaking traditional UNIX tools is a common exercise when learning system programming. And because Rust is quite trendy nowadays, I guess a lot of people wanted to try it out, and in some cases, that exercise turned into a viable product. Nim never got the same popularity.

deleted 5y ago

[deleted]

deepsun 5y ago

How about Busybox?

deeviant 5y ago

If were talking about libs and APIs then game on, but otherwise, I actually don't care what language a tool is written in. I care how good the tool is. No, I don't think you will find a high correlation between language and tool quality.

NextHendrix 5y ago

If rewriting in a safe language is the main driver why not rewrite everything in Ada instead of Rust?

Narishma 5y ago
You'd have to ask Ada programmers.

ibraheemdev 5y ago

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 all tools that may be useful to people, rather than excluding some simply because of the creator's choice of language. [0]: https://github.com/ibraheemdev/modern-unix https://github.com/ibraheemdev/modern-unix

senderista 5y ago

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?

senderista 5y ago

Would you like to replace a C program written by djb with a Rust program written by Uncle Bob?

geodel 5y ago
Ah Uncle Bob,the philosopher of programing methodologies. I'd imagine writing any program beyond hello world with 100% test coverage would be beneath him.

senderista 5y ago

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.

justwalt 5y ago
Why do you think that most modern software should be written in a GC language?
- sweeneyrod 5y ago
  Would you consider using a non-GC language that isn't Rust outside the various domains where C/C++ is the only realistic (non-Rust) choice?
  - senderista 5y ago
    Deterministic memory deallocation makes it harder to reason about not just “easy” code, but also linked structures and lock-free algorithms (actually it is a substantial implementation obstacle for the latter). It must offset these costs by providing predictable latency or low memory footprint. Most applications don’t require either.

the-alchemist 5y ago

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. borkdude has been releasing for some very cool stuff using this stuff. Here's a Clojure/Rust combo: https://github.com/borkdude/clojure-rust-graalvm https://github.com/borkdude/clojure-rust-graalvm

dividedbyzero 5y ago

Still trying to get into both Go and Rust – is there something about Rust that makes it a better choice for such CLI utilities than Go?