The problem I see is that I don’t see those consolidating anytime soon into a new set of ubiquitous “core” utilities that can be expected to be available everywhere.
That doesn't solve the "available everywhere" problem. It potentially would make the tools easier to install on Debian-based systems, if you have root access. I'm not sure any new set of tools will ever be available with the ubiquity of coreutils in the next handful of years, if ever.
I agree. If these could be made installable without root, and independent of the current version of glibc, then there is huge potential to replace the older tools. I’d love to use things like fd, but they don’t work on older servers without root and a newer version of glibc
Local installation is still not really a practical solution when you work e.g. on customer machines, on machines of another team, or generally if you work on many different machines. You still need to be aware of the standard tools and know how to use them when needed.
I mean, I get it — I used to locally install vim on machines that only had vi, to make my muscle memory be functional when editing files. But it’s not the same as a core tool just being available by default so you don’t have to ever concern yourself with any alternatives.
This is why I like that you can "go run" golang programs without installing them. Anywhere golang is installed it will automatically build cache and run the binary for whatever platform you are on.
There’s moreutils for an older rethink of the same set of utilities. I don’t see why an evenmoreutils wouldn’t eventually become popular enough to take hold? Probably not as quickly as you’d like in today’s world of instant gratification, but we’ll get there, eventually.
moreutils is still nowhere near as ubiquitous as coreutils. For me it's not about gratification. It would be more satisfying to make use of the most modern tools available. It's about making sure stuff works and I find sticking to coreutils is the easiest way to do that most of the time.
I use Cargo regularly and rustup it does make it easy to install. That's not the point. I'm not looking for a package manger. I want to be able to write scripts that make use of tools I can pretty much guarantee are already installed.
My primary point is that if I stick to coreutils, I don't have to worry about any of this. I can reasonably expect anything in coreutils to already be installed and available. Your functions seem like they'll work just fine, but either requires build tools to be installed, or the package to support binstall. For me, thinking about all these things and maintaining something like that isn't worth it when I can just use coreutils.
I suppose I shouldn't have said only Debian. But having tools easily installable is still quite different from being able to reasonably assume they are already installed.
I wonder how well Rust project get along with Debian packaging tools.
"Modern" dev environments are often tied to their own package manager. JS has Npm, Rust has Cargo, etc... These have their own dependency managers, version systems, etc... and they don't always get along with the way Linux package managers work.
IIRC, you don't even need Cargo to do Rust, so it should be possible to compile Rust projects like you compile C projects and essentially mirroring crates.io but with .deb packages but it looks like a lot of work.