[laumars]

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.

[singhrac]

I mostly agree with this sentiment but I think it's not that necessary to point out. Yes, some of these are abandonware but many are written by the same set of strong Rust programmers. I think you'd be hard pressed to argue that ripgrep or fd is not a valuable contribution to the OSS ecosystem.

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

[laumars]

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

[Zababa]

> I find it more interesting to ask the question "why do people spend so much hobby time writing interesting programs in Rust?".

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.

[smitherfield]

> because you don't have a reason to reinvent the wheel [in Rust]

This is a somewhat comical statement in a thread about "Rewrite it in Rust."

[b3morales]

Nah, the thread is about people redoing the whole car, adding airbags, swapping out the carburetor, installing power steering, and maybe throwing in a new stereo and a paint job.

sed vs. sd, for example https://github.com/chmln/sd The semi-lovable but reliable old jalopy overhauled to match modern practices.

[deeviant]

> but I suspect the real reason people built high quality software in Rust is because cargo is good

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?

[staticassertion]

It's way too hard to build evidence for something like that. Virtually all research into PL effectiveness ends up not account for the absurd number of variables.

[bfrog]

One metric might be how long it takes a developer to build it from scratch given all the esoteric builds in C/C++ land. Another might be lines per cve in a given language. Another still might be time to fix cves per language.

I'm thinking rust would come out on top of those, but would be interesting to measure!

[DoctorOW]

How does one objectively measure quality in a way that isn't dependent on the specific goals the program is trying to accomplish?

[secondcoming]

It's unlikely that this evidence exists, and if the 'clone everything to get past the borrow checker' attitude is commonplace then we get stuck on what 'high quality' means.

[jlg23]

> I find it more interesting to ask the question "why do people spend so much hobby time writing interesting programs in Rust?".

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.

[gspr]

I wholeheartedly agree.

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.

[Thiez]

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

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.

[Zababa]

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]

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

[cestith]

My take is that was just poor wording and they should be considered alternatives or potential future replacements in progress. Once you give up on that word, the page makes more sense.

[laumars]

More sense in one regard but less sense in another. If you’re curating a list of alternative software that is acknowledged not to be mature in all instances, then the arguments for making it Rust specific become moot since it’s no long a curated list of more secure software.

[benibela]

I have been rewriting things in Pascal for years, because it is much safer than C, and no one cares about that :(

[a-nikolaev]

That's awesome though!

[bdamm]

Somehow this feels like sarcasm, given that Pascal is older that pretty much everyone on this forum.

[insulanus]

The novelty of a tool is not directly correlated to its worth, because we can always make new, worse tools.

Newer tools CAN make use of new information in a better design, but it doesn't always happen.

[benibela]

Seriously: https://github.com/benibela?tab=repositories

I have been doing it for 20 years, and all the time Pascal had null-safe strings and C-like performance. And the strings even had mutability xor aliasing with copy on write

[pjmlp]

Imagine an alternative reality where Borland did not went greedy, Java 1.0 would just be like Go, while .NET Native would just be improved VB 7 and a new language C# (just a kind of "managed C++") making COM developer friendly without C++ boilerplate that persists to this day.

[pizza234]

This is an accurate view. The "Awesome" meme is indeed a bit dangerous in this case :)

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

[DyslexicAtheist]

> looks more like some misguided worship to a single language

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)

[pjmlp]

In what concerns Zig, I would rather have the use-after-free scenario be taken care of before the whole RIZ starts.

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.

[zozbot234]

> 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

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.

[stared]

I don't like the word "replacement" either. If something works, something works. Very often, it took a lot of time to polish the tool. It won't be easy to recreate all of the functionalities - even if using a new technology making it easier to develop software.

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

[alpaca128]

As a fan of the language I also don't get this. I mean I welcome wider adoption of Rust for various reasons, but this whole "it's written in Rust!" checkbox filling doesn't have any connection to what matters in reality.

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.

[pdimitar]

Would you feel better about this is if the badge was "Written in a memory-safe language"?

[cerved]

tbh, I would feel better if the badge was "tested for 50 years on every system you can think of"

[pdimitar]

I, too, enjoy sci-fi. :)

[cerved]

cat has been around for 49 years and 8 months, give or take a few days

[pdimitar]

Sure, there are a few of these around. 99% of the software you use every day has been around for less however.

[hulitu]

Is a memory-safe language a safe language ? Is it not possible to exploit rust ?

[pdimitar]

Of course it is possible. If you get your hands on the binary itself there's nothing that a good reverse-engineer will not be able to do.

Point however is, if you have a SaaS which uses Rust, the chances for triggering a buffer underflow / overflow exploit are zero.

As for other aspects of security, Rust makes no special effort there. The main win for using Rust is to eliminate the most widespread bugs (the memory safety ones) from the get go. Everything else is still fair game and has to be paid proper attention to.

[clappski]

> the chances for triggering a buffer underflow / overflow exploit are zero

Doesn't the mere existence of unsafe make this untrue? From a quick google I can see at least one[1] so the chances are definitely a lot higher than zero

[1] https://github.com/servo/rust-smallvec/issues/252

[burntsushi]

The GP is either being incorrectly absolutist, or left out an important qualifier: "In safe Rust, the chances of <insert memory safety problem here> are zero."

But that is also absolutist. Instead, you might say, "In safe Rust, the chances of <insert memory safety problem here> are zero, modulo bugs in the compiler."

But that's not quite the fully story either. So instead, you might say, "In safe Rust, the chances of <insert memory safety problem here> are zero, modulo bugs in the compiler or any dependencies or any other uses of 'unsafe' in your application."

And maybe that's still not quite it. So let's try again: "In safe Rust, the chances of <insert memory safety problem here> are zero, modulo bugs in the compiler, any dependencies or any other uses of 'unsafe' in your application and any other platform specific tricks for arbitrarily rewriting memory used by your process."

That probably covers it. But it's a mouthful. It's probably best to avoid saying the chances of anything are zero. Instead, the key value add of Rust is that it flags areas of code that permit introduction of UB for easier auditing, and also enables building safe---for all inputs---abstractions for others to use. But humans are fallible, so there is and always will be an opportunity to fuck something up somewhere. What Rust gives you over something like C or C++ is a way to make assumptions that are more fine grained than, "I trust that every line of code written in the transitive dependency chain is free of UB."

[sweeneyrod]

I don't think memory safety bugs are the most widespread kind at all, unless you add the qualification "in languages with manual memory management".

[steveklabnik]

I imagine what they're alluding to is that it seems like most of the security bugs are memory-safety related. The number is about 70%, and has been replicated independently at a number of places.

That is of course a very different thing!

[username90]

Rust isn't a memory safe language though. Unsafe is a part of the language, so it wouldn't get that badge.

[pirocks]

Pretty much ever safe language has unsafe features though, either by calling out to C or something like sun.misc.Unsafe in java.

[username90]

Calling unsafe libraries isn't the same thing as having unsafe language features.

[alpaca128]

Calling unsafe libraries automatically makes the calling code unsafe by definition. You cannot have a 100% safe language that also interacts with its (unsafe) environment in any way.

The language needs a way to express the lack of safety of an external library in order to clearly isolate it from the safe code sections. In Rust that's the unsafe block.

[pdimitar]

unsafe{} is an explicit escape hatch so it's much easier to audit and control for. So you are simply nitpicking.

[valenterry]

To me it makes sense. I predict the future of the tool/product partly on the technology, and the programming language is part of it

[pxc]

I wonder if in the future, it will be easier to find contributors for Rust projects than C projects, just because Rust is more pleasant to use.

[fnord77]

I don't think it is worship - I think rust fans find rust fun to program in and thus are looking for projects.

[afarrell]

> And a lot of those projects are just someone’s pet project, often written as a task for learning Rust

I think 40% of the complaints people have about new JavaScript frameworks are from people failing to have the analogous insight to this.

[pdimitar]

JS most of the time works inside some of the biggest and most strictly reviewed software packages in the world -- the browsers. JS needn't be concerned with memory safety, only not to allow (too big of a) memory leak.

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.

[marcus_holmes]

If a common question in a job interview is "have you written any OSS projects that are used by others?" and a positive answer is expected, then this is where we end up.

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.

[goodpoint]

...then they get the job and the library or tool goes unmaintained.

Endless churn ensues. See the javascript ecosystem.

[goodpoint]

To clarify: I'm in no way opposed to experimentation, learning and weekend projects.

But there current "github-centered" development culture makes it very difficult to tell if authors are invested in their FOSS projects are going to maintain them or not.

As the churn keeps increasing we can end up with ecosystems collapsing.

In comparison, the library maintained since 2003 by the Nebraska person is less worrying. https://xkcd.com/2347/

[marcus_holmes]

Also, the "don't write code, just find a library that does what you want to do and plumb it in" mentality means that people approach a problem by searching Github, find these half-finished experiments, and ship them to prod.

I exaggerate, of course, but not by much

[goodpoint]

This is why FAANGs rewrite a lot of stuff. Having control over a library developed internally VS being at the mercy of random accounts on github.

[brailsafe]

Uh, is this a common question? I've never been asked anything remotely close.

[lbhdc]

I get it pretty often. I am assuming they want to use this as a means to see code that I have written in collaboration with others.

[nicoburns]

I get it pretty often too. Having said that, I haven't typically had much to show and I've usually been offered the job anyway so I'm not sure it's typically given that much weight.

[blacktriangle]

I've asked that question. I use it as a way to offer an alternative demonstration of work to developers who are early in their careers. It's not about seeing the code as much as it is wanting to see that a person has taken software through the full lifecycle. I'd rather see an app in an App Store or a live site on the web, or even just talk about an in-house project that they've managed over a period of years.

[nicoburns]

That makes a lot of sense. Most of my github projects are from prior to my first job, which I was quite proud of at the time, but are somewhat less demonstrative of my skill level now over 10 years later.

[pjmlp]

This is how my github is a mix of almost 30 years old university assignments and unfinished weekend projects.

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.

[pdimitar]

This is not unique to Rust, it happens with literally every language somebody gets hyped with.

[marcus_holmes]

I agree, I see the same thing happening in Go - there are endless pointless libraries being developed and published for no reason except as filler in people's Github accounts for recruiters to look at.

And of course Javascript... shudder

[zurn]

Are you implying that Rust is only / mostly used as a replacement for unsafe C/C++, and Rust programs should always be evaluated in the context of this choice?

[laumars]

No, I’m arguing against that mindset. The git repository is what raises the “Replaced It In Rust” argument.

[zurn]

The safety issue or comparison against C/C++ was not mentioned in the submission. So I don't follow why the protest against replacements for Haskell programs, based on a safety argument.

[staticassertion]

For CLI programs Rust is a really nice alternative to languages that require a runtime. I've significantly sped up the time for my bashrc to execute (my bashrc is heavy) by replacing certain tools with Rust tools.

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.

[atombender]

ShellCheck starts in a few milliseconds on my machine, easily fast enough to run on every character press. Haskell's runtime isn't like the Java JVM, and GHC compiles to machine code, not interpreted bytecode.

[staticassertion]

Nice, that's impressive.

[whateveracct]

I really doubt the GHC RTS is appreciably slowing down ShellCheck. Especially if its built with RTS flags optimized for startup. Feels like optimizing the wrong thing a bit.

[kevinmgranger]

The page claims they're awesome, it doesn't claim they're better.

[laumars]

The page has been changed since my post. It originally called them “replacements”, which paints a totally different picture. From reading the GitHub Issue thread regarding the name change, it sounds like various people on Reddit were making similar concerns about the original choice of wording too.

[schwartzworld]

> yet this list parades a Rust counterpart to Shellcheck as if it’s automatically better just by the fact it’s written in Rust

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.

[pjmlp]

Indeed, in fact the Microsoft Security Guidelines explicitly states .NET languages should be taken when having a GC around is not a show stopper.

[gkfasdfasdf]

Ditto re. fzf. Fzf works amazingly well and is a recent development, who cares if it's not written in Rust?

[volta83]

> just by virtue of being a ground up rewrite.

by potentially beginners.

[mamcx]

> I’m fully in favour of using newer and safer languages...

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.