It frankly doesn't seem like a deprecation in the traditional sense.

tools like ls or grep are certainly showing their age, but that has also been their strength. The POSIX ecosystem comes in many flavors but I can always depend on it.

It’s not like I can ever expect to shell into any arbitrary system or container and expect to have exa/lsd/rg or any of these nice replacements available to me. My tooling needs to be somewhat more portable.

Ah yes, because it's 100% impossible to learn new tools and fall back to the core ones when you need to. ;P

I've been doing this for decades now, it's just not that big of a deal.

   if [ -z "$(which exa)" ]
   then
     LS1='ls -1'
   else
     :
   fi
   ${LS1} ${SOME_DIR} | ... 

?

But if what the comment I replied to meant by "capable of maintaining them myself" was about having an organizational structure where they could become an official maintainer of the official project rather than needing to fork it if the owner becomes unavailable, then yep, that's a great point about these single-owner projects.

But my original interpretation was about the difficulty of maintaining the code. To me, these rust tools are a huge improvement in that way.

But in practice, the tooling for making those tools never got very good. (That is, in my opinion - there is at least one commenter here who replied to me about actually liking autotools, which is fair enough, just not my opinion.)

So while fully recognizing the value of the old tools that will always exist, for new useful tools, I'm very happy to see this renaissance of writing them in rust. In my opinion, it is much easier to build them, dig into their implementation, and contribute to them (especially without introducing security vulnerabilities or data races).

Where I do absolutely agree, and what I do wish for is that more of this were being done under the auspices of an organization, like how the `ls` most of us are using is likely maintained by either GNU or one of the BSD organizations.

After not noticing for months, because exa kept on wokring fine and still being more pleasant than `ls`. Oh noooooo.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

Which ones gave you trouble?

A timeless tautology.

Some things just are easy and pleasant. Caddy server, Cargo, ripgrep come to mind. Some things are easy only once you've learned them. No kidding!

Agreed that cargo has bugs and I hope it improves over time (granted: it is not at all new). But say what you want about cargo, at least it's an ethos!

> I saw a book entitled "Die GNU Autotools" and I thought "My feelings exactly". Turns out the book was in German.

https://twitter.com/timmartin2/status/23365017839599616

gnu autotools i suppose works for some projects, but wow does it seem to be completely annoying to use.

Even VS Code uses it for its search beneath the hood.

Related: the Lindy effect (https://en.wikipedia.org/wiki/Lindy_effect)

Beware of [HN] bias. People are very quick to rain on Rust for reasons none of them have ever explained substantively and with facts, and many others are quick to agree without checking.

I'm not sure what this paragraph is doing in this context. I was specifically talking about my own experience. I see far more praise for Rust compared to negative comments in any case, and was biased towards assuming "Rust rewrites of tools may lack features (due to being newer) or be less portable or whatever else, but the one thing they'll have is stability and reliability". That came crashing down when exa crashed and core dumped.

It didn't turn me into some anti-Rust fanatic either (which people seem to interpret any criticism of Rust-related things as), it just made me realize that in the end it's still up to the individual tool and programmer, and I shouldn't make strong assumptions based on the language a tool is written in.

Just a small precautionary statement. I've observed it enough times to get very wary of it.

> I see far more praise for Rust compared to negative comments in any case, and was biased towards assuming "Rust rewrites of tools may lack features (due to being newer) or be less portable or whatever else, but the one thing they'll have is stability and reliability".

Filter bubbles in a nutshell, I usually see mostly negative ones and barely see any praise (though I'd define "praise" here as "fan-boying", and NOT as "recognizing the strong sides"; the latter is quite normal and should not be called praising).

> That came crashing down when exa crashed and core dumped.

That's the part I find a bit overly dramatic, this was likely Rust's `panic` mechanism so they likely just didn't handle an expectation / assertion in the code? I had several Rust services in production for years and former colleagues have contacted me to tell me the thing hasn't crashed even once and was only ever restarted for upgrades.

> It didn't turn me into some anti-Rust fanatic either (which people seem to interpret any criticism of Rust-related things as), it just made me realize that in the end it's still up to the individual tool and programmer, and I shouldn't make strong assumptions based on the language a tool is written in.

Yes, fair. If you pepper your Rust code with `.expect()` and `.unwrap()`, the program ending abruptly is expected because the team hasn't taken precautions to handle all possible errors.

Mine is that they're ubiquitous and I can rely on them existing on all Unices. For the same reason, I avoid getting used to any features that are unique to a particular platform or distribution. It just causes additional friction when I'm working on a different system.