Live data from Hacker News

Replacements for existing software written in Rust

github.com

41–50 of 229 posts

Re: Replacements for existing software written in Rust

#41
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…

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.

Re: Replacements for existing software written in Rust

#42

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.

Agreed. I will put it even more directly.

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.

Re: Replacements for existing software written in Rust

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

Re: Replacements for existing software written in Rust

#44
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…

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.

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

Re: Replacements for existing software written in Rust

#45
post #12
post #7

Earlier quoted context omitted.

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.

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.

I cannot upvote this comment enough. This list of tools are tried and trusted, and have under went 1000s of hours of usage.

Sure that given enough resources, motivation and time, Anything is possible. But new code means bugs and uncertainty.

Some of the tools listed are not small if a one for one replacement is the target. Vim is listed??

How long before these tools are considered as matured and ready for production?

Re: Replacements for existing software written in Rust

#46
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…

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.

Re: Replacements for existing software written in Rust

#47
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…

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

Re: Replacements for existing software written in Rust

#48
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…

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.

Damn, for me it breaks every couple months

Re: Replacements for existing software written in Rust

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

Re: Replacements for existing software written in Rust

#50

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!

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.

Post reply on HN