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.
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?".
Probably for the same reason people spend so much hobby time writing interesting programs in other languages: because they either already have experience in that language and like it or they’re looking for an excuse to learn a new language.
Personally I don’t find it an interesting question to second guess why people have hobbies. Sometimes people enjoy challenges because they’re easy, but sometimes people enjoy challenges because they’re hard. My wife relaxes by watching TV. I relax by writing OSS. Everyone is different.
My theory is that people that like Rust want to work with Rust, and for that the best way is to prove that it's a good <language> replacement in <space> multiple times. By making modern and good versions of classic CLI tools, they prove that it can replace C in that space. By making good new CLI tools, they prove that it can replace Go (that replaced Python/Ruby) in that space. Some people are trying to replace JS on the frontend (Yew), some people are trying to use it in the backend (Rocket, Actix). Some people working on chromium were (I don't know if they still work on it) trying to prove that it can replace C++/a GC'd language while having the benefits of both. There are lots of examples like that.
Rust often ended up as the most loved language on the stackoverflow survey. I don't know if it's intentional or not, but people in the community seems to understand than marketing is important, and proving your claims is too. And the best way to prove your claims is to deliver working software that's at least as good or better than what was previously made in <language> in <space>, to prove that you could use Rust here.
Of course as you said, cargo really helps here. I'd say other big players are the culture and the type system. The type systems acts as a first layer of documentation and helps ship better code. The culture is also heavily focused on documentation and welcoming newcomers. Compiler errors are a joy to read, rustfmt is a nice addition, clippy is also very good, and people tend to be very nice and welcoming in the community.
What I like with this explanation is that is also in part explains the rewrite it in Rust (RIIR) obsessed people: they see how the community act, fail to understand that delivering working code is the most important part because it's less visible than the "pure marketing" talk, and so blindly repeat the "pure marketing" talk.
This is a somewhat comical statement in a thread about "Rewrite it in Rust."
Do we actually have factual evidence that people do write high quality software in Rust.
Something showing the average rust program is "higher quality" than the average C++ program?
Maybe just as a learning experience or to be able to say "I know $hypedLanguage." Nothing against rust on my side, but at least for me, time spent on writing something in a language new to me is in no relation to my perceived usefulness of that language.
I personally believe that people new to programming love rust because they get compiler feedback instead of runtime errors. Given what is currently en vogue, rust does stand out there. OTOH, if looking at some old, boring languages, you already have that. Minus the hype.
Especially since one huge strength of Rust is its C interoperability, one would imagine that incrementally replacing or extending parts of the legacy tools would be a much more sound approach. But of course, the point you make does answer this:
> 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.
Many of the replacements are indeed not meant to actually replace the tools. They're learning projects. That's great, but it's a bit scary that people wanna use them for anything else.
When it is unlikely that the maintainers of existing tool written in C would accept pull requests that add Rust as a dependency (and I imagine this would usually be the case), why wouldn't you start anew? It also allows easier experimentation on the architecture of the original tool, and breaking compatibility. For example, ripgrep isn't a drop-in replacement for grep and the author never intends it to be, so forking grep probably wouldn't have made it easier to develop.
I think the difference between a learning project and a "real" project is mostly how many people end up using it.
> 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) ?
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.
Something important to be noted that RIIR does not represent the attitude of the Rust community - actually, the instances I've read until now were from people who had little or no experience.
I think this distinction is important because there are some negative attitudes attributed to the community that I personally haven't found (e.g. "screaming" how good Rust is; committed/professional Rust developers are already busy screaming at the BCK ;)).
this pretty much sums up Rust atm. There is a lot of hard-core evangelizing which is off-putting imho. I still like the language but wonder if a rewrite for rewrite sake will convince the majority, considering this is a community effort and not a large org controlling the future of the language. Especially that there are other ecosystems like Zig or Nim that are pretty cool too and fit into a similar niche. Hard-core evanglism just feels like advise from somebody who's only tool is a hammer.
on the other hand I do remember the amount of marketing and advertising budget that Sun and later Oracle pumped into Java to make it fly in the late 90ies. They made deals with University professors to make sure the language is favored. It was a hype-shit machine unmatched by anything we've seen since (and when I use the word shit I mean your browser being hi-jacked and reconfigured with a new toolbar and a search engine simply because you installed a JRE. not too different from how malware behaves). It's not that early Java was terrible (though it certainly over-promised and under-delivered for over a decade) but if Java would have had to grow organically back then like Rust/Nim/Zig do today, then Java wouldn't have stood a chance. There were even ads at airports and on TV. Ads for a programming language during a time most people watching TV didn't know or care what computers are for!
So I'm quite glad that this is just a couple of people who are overly excited about what they do. We've had a lot more asymmetry with larg-corp sponsored garbage. Go Rust!! (and Nim and Zig)
Regarding Java, it had a major killer feature that triggered adoption even before the whole marketing wave started.
It was actually portable, not like trying to write C or C++ code in the middle of ongoing standards, compilers still stuck in the old ways, POSIX on paper and on actual UNIX clones not being 100% the same thing.
It was like a fresh air of portability even with an interpreted runtime, JIT only came in by 1.2 days.
I think there's an obvious case for being aware of rewrites from high-level memory-safe languages (not just Haskell, of course) to Rust, although the case is obviously different from rewriting C/C++ code. Besides the obvious improvement in performance (Rust being on par with C/C++ itself) it gives us a better idea of whether Rust is actually missing features from these languages in a way that meaningfully impacts maintainability.
At the same time - I see the list as a testament to enthusiasm about Rust. People use it. People try to reimplement things. Also - it is likely that one day one of these reimplementations will take over (due to performance, functionality, or simply - because of being maintained).
If you're rewriting something anyway, or creating something new then Rust should be considered. But a lot of the value of old software is not the set of features listed in the Readme. Not every area comes with its own "don't roll your own crypto" warning, but almost everything has its share of edge cases and quirks that were already handled in existing tools.
I think 40% of the complaints people have about new JavaScript frameworks are from people failing to have the analogous insight to this.
Rust solves another problem. Most of the security vulnerabilities out there come from buffer underflows or overflows.
Rewriting tools people rely on every day in a language that prevents those is not failing to learn from JS.
Thousands of new developers, eager to learn Rust and get a job, rewriting anything they can get their hands on and pushing it out for the community to use.
Endless churn ensues. See the javascript ecosystem.
To tick the checkbox of some HR people that insist that I provide something.
Total amount of times anyone asked me anything about them on a job interview, zero.
If I wanted my IDE to execute something like ShellCheck on every save, or even every few character presses, I feel like I'd much rather not have to spin up a big runtime.
You're perceiving a sentiment from the list that I just don't get. All it is is a list of alternatives written in rust. The fact that they're written in rust, is really only valuable to people who are already interested in rust.
by potentially beginners.
And the ONLY way C/C++, that cost BILLONS on bugs alone, is replaced is that people rewrite things on something better (and Rust IS better).
And this start for fun.
And it could get new bugs? yeah... but it also NOT continue the old bugs that C/C++ cause, some that will be erased of existence (like nulls) for the rest of the life of the codebase.
And this is the point. Logic bugs eventually are squashed, but language design mistakes are nearly eternal for the life of the codebase.
* joy of coding
* (human) efficiency of coding
* performance of idiomatic code
* interoperability with C
* deployability
I'm totally sold on Rust. Yet: Why would I want to replace tried and tested tools with new versions just because they're written in Rust?
I burned myself on this when I was young and naive: Having just learned Haskell, I tried to use Haskell replacements for everything. It was incredibly stupid and counterproductive (the biggest real-world pain was clinging to darcs over git for a long time at the beginning of the DVCS wars – not because of darcs' arguable good features, but because it is written in Haskell; so stupid).
* Old tools are well established, not looking for major feature additions or changes
* Hard to add new features to old C-based system tools due to mature codebase and being written in C
* Using Rust to reach a low-bug/maintainable state more quickly than a re-write in C or C++
* Adding a bunch of quality of life features that make it worth switching
The big downside with these tools, of course, is that they are re-writes of tools that have been standard Linux/Unix system tools for a long time and can be generally expected to be present on any system for the purpose of shell scripts, services etc. Using any of these tools in a shell script requires the user to install it, along with the whole dependency graph that rust typically comes with (at least when building from source which is typically the case with rust).
I don't believe performance will be significantly different if you're comparing a C vs a Rust tool though.
I absolutely care if the BT stack of my phone is written in a safe language, because many of the security flaws that make many, many Android devices permanently unsafe (due to end of support) are caused by memory unsafety.
On the other hand, I have the suspicion that Rust is voiced a bit too much by a loud minority - I like Rust as much as I don't like Golang, nonetheless I think that for the majority of non-performance critical projects, Golang may be a better fit.
I could not care less about the hype squad screaming endlessly about every single side project that is written in Rust because of the sake of the language. If it is useful and it makes me money then fine, other than that I ignore it.
If the tool that is being developed doesn't help me make money, then I do not care or I won't use it.
As for choosing the best programming language? I do not care unless it is the one that makes me the most money. in some use cases, it is definitely not Rust.
This is Hacker news. It's news for people who want to fuck around with tech.
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.
# `rg` / Ripgrep (`grep` replacement)
`rg` uses `ack`-semantics (i.e., automatically searches files recursively).
Here's what my search workflow looks like, this is the main way I program:
1. `rg something`
2. Too many hits? `rg -l something` to just list matching filenames
3. Hopefully based on that we can narrow enough using a glob: `rg something -g "*.m"`. Otherwise write a regular expression to get more specific matches.
4. After I have exactly the set of matches I'm interested in, I pipe the results to a text editor that can interpret grep-style output (e.g., quickly jump between results, I usually use Vim).
The key here is that the command-line excels at iteratively refining a command based on output, and that's exactly what we're looking for to use search effectively. `rg` provides a more ergonomic UI than `grep` (recursive, automatically ignoring version control files, including ignored), which is really important if this is the main command that you're running all-day, which it is for me.
# `fd` (`find` replacement)
This advantages here are the similar as for `rg`, quickly being able to recursively find a file by name, a problem that similarly benefits from iteratively refining a command.
# `bat` (`cat` replacement)
`bat` is just the best way I've found to quickly view a file from the command-line, it adds syntax highlighting and line numbers, which are both invaluable.*
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.
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.
Same with POSIX tools and their replacements: `find` is perfect when I know I'm going to run a script on a bunch of similar Linux hosts where I can't count on `fd` being available, but if fd is around I'm definitely going to use it at the shell prompt over find. As a side note, if you're doing cross-platform work, the new tools are better in some ways than the things they're replacing. Sure, `fd` isn't going to be installed by default on our out-of-the-box EC2 instances, but once it's installed at least it has the same arguments on Linux as on BSD and macOS. If I'm going to have to install GNU utils on a system to manage it, it's no extra work to install fd at the same time.
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.
Apart from that, most modern languages come with a package manager nowadays. Why do you like rust more than go? Or nim? Or elixir? Or crystal?
But I never, ever had it just fail to install a package, and I don't remember much fuss with dependency resolution taking manual fiddling, either.
I'd love to hear your pacman horror stories; gimme the hot package manager gossip :D
These days, I prefer Linux distributions or BSD ports, though Homebrew seems to be pretty casual as well.
The last straw for me was being unable to do something simple like install vey common Perl packages natively via CPAN.
Rewriting in a memory-safe language is worth it. But it shouldn't be a religion, I completely agree on that.
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.
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.
Does anybody miss Sendmail? That had also "stood the test of time".
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.
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?
Regarding TUIs, have a look at thes screenshots and example codebases for these libraries:
https://crates.io/crates/spotify-tui
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.
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/)
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-tea...
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.
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.
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.
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.)
borkdude has been releasing for some very cool stuff using this stuff. Here's a Clojure/Rust combo:
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.
No, I don't think you will find a high correlation between language and tool quality.
