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

61–70 of 229 posts

Re: Replacements for existing software written in Rust

#61

Post by pdimitar »

afarrell wrote: post #23
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…

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

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.

Re: Replacements for existing software written in Rust

#62

Post by pdimitar »

alpaca128 wrote: post #43
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…

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…

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

Re: Replacements for existing software written in Rust

#63

Post by marcus_holmes »

pdimitar wrote: post #58
marcus_holmes wrote: post #54

Earlier quoted context omitted.

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.

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

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

Re: Replacements for existing software written in Rust

#64

Post by pdimitar »

sharperguy wrote: post #28
gspr wrote: post #13

Earlier quoted context omitted.

Ditto. And I'm one of Rust's recent happy converts – it's probably the language I've learned that scores the highest ever when it comes to the unweighted sum of * 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?…

It seems the new culture around re-writing these tools in rust starts with a few premises: * 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 m…

I agree with you about the ubiquity of the standard tools but this also has downside: bigger size of the deployment containers.

Nowadays the distroless movement and the general zeal towards minimizing the overhead of a Docker image have the positive side-effect of making us less reliant on the older tools. So we can opt for newer ones (although it's very hard to beat 120KB of a classic old tool to 4MB of a new Golang/Rust tool still).

As for rewriting in Rust, the main point for me is always the memory safety. When it comes to writing programs, there's a ton of very nice languages out there already.

Re: Replacements for existing software written in Rust

#65

Post by Zababa »

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

Re: Replacements for existing software written in Rust

#66

Post by pdimitar »

lmm wrote: post #31
ex_amazon_sde wrote: post #29

Earlier quoted context omitted.

There are plenty of memory-safe languages equally suitable for similar CLI tools and, arguably, easier to write than Rust.

I don't disagree - IMO 95% of what's written in Rust should have been written in OCaml years ago. But often those languages aren't used, for whatever reason. If Rust is what gets us the actual big rewrite into memory-safe languages, I'll take it.

OCaml's community has been pretty elitistic up until just some few short years ago. Stuff like "build your project", "build docs", "generate parts of your project" have been a dark territory there for a long time where people invent their own stuff and just look down on many others who want an experience similar to Elixir's `mix` or Rust's `cargo`.

This is changing, happily, but OCaml I always viewed as kind of an elitistic intellectuals club. Happy to be proven more and more wrong lately, though!

I am looking forward, eagerly, to OCaml 5.0 and having an amazingly fast compiler with solid multicore runtime system support! It's very likely I might abandon Rust for OCaml when that time comes (8 - 12 months).

Re: Replacements for existing software written in Rust

#67

Post by pdimitar »

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…

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.

Re: Replacements for existing software written in Rust

#68

Post by pdimitar »

afarrell wrote: post #27
coldtea wrote: post #24

Earlier quoted context omitted.

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

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.

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

Re: Replacements for existing software written in Rust

#69

Post by zozbot234 »

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…

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

Re: Replacements for existing software written in Rust

#70

Post by goodpoint »

goodpoint wrote: post #57
marcus_holmes wrote: post #54

Earlier quoted context omitted.

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.

...then they get the job and the library or tool goes unmaintained. Endless churn ensues. See the javascript ecosystem.

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/

Post reply on HN