Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Replacements for existing software written in Rust

github.com

Post reply on HN
Print view View original

111–120 of 229 posts

Re: Replacements for existing software written in Rust

#111

Post by Zhyl »

dlivingston wrote: post #105
Zhyl wrote: post #52

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 sens…

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 stan…

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.

Re: Replacements for existing software written in Rust

#112

Post by Zababa »

singhrac wrote: post #102
laumars wrote: post #8

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 Sh…

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 q…

> 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 replacement in 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 in , 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.

Re: Replacements for existing software written in Rust

#113

Post by stared »

laumars wrote: post #8

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 Sh…

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

Re: Replacements for existing software written in Rust

#114

Post by volta83 »

laumars wrote: post #8

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 Sh…

> just by virtue of being a ground up rewrite.

by potentially beginners.

Re: Replacements for existing software written in Rust

#115

Post by EamonnMR »

bruce343434 wrote: post #4

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!

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.

Re: Replacements for existing software written in Rust

#116

Post by ironmagma »

bruce343434 wrote: post #4

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!

As many say, open source is about choice. There are no choices if there’s only one of each thing.

Re: Replacements for existing software written in Rust

#117

Post by ironmagma »

twa10 wrote: post #49
csomar wrote: post #39

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…

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 These days, I prefer Linux distributions or BSD ports, though Homebrew seems to be pretty casual as well.

Cargo can handle dependencies linked via URL. Crates.io may be a moderated centralized database, but Cargo is just a neutral tool like make or Cabal.

Re: Replacements for existing software written in Rust

#118

Post by laumars »

singhrac wrote: post #102
laumars wrote: post #8

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 Sh…

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 q…

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

Re: Replacements for existing software written in Rust

#119

Post by laumars »

Zababa wrote: post #65
laumars wrote: post #8

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 Sh…

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 t…

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

Re: Replacements for existing software written in Rust

#120

Post by b3morales »

smitherfield wrote: post #104
singhrac wrote: post #102

Earlier quoted context omitted.

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 q…

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

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.

Post reply on HN