I know, but coreutils also literally never broke on me as they are. To me, the whole point of coreutils is that they’re just… there. I’ll leave the decision to change bundled tooling to distro maintainers.
I’ll also be perfectly honest: from a developer standpoint, end-users caring about the language a tool was developed with is, in the end, a pretty weird concept to me. Memory safety and cross platform compilation is DX stuff. Nothing tells you as a user that the thing you’re using isn’t sprinkling unsafe everywhere, in the end… The application itself doing what it advertises is what I’d expect most users to care about. Especially for stuff as old and relatively stable as most coreutils.
If you go to the uutils repo you can see that it’s making proper use of fuzzing, test, etc. and only makes use of unsafe in necessary areas.
Uutils is also more consistent with modern standards thanks to clap & uniform design, has out of the box selinux support, etc.
if you use a reference in unsafe code, it will still be checked.
Also many distros are already packaging uutils do to it “growing into remarkably robust shape”, it’s just not ready to completely replace coreutils quite yet and so it’s not up for consideration by distros to ditch coreutils until it’s at least at parity.
(That’s why I make use of hybrid and not outright replacing everything).
The point is not the language, it’s how the project is making use of the language and uutils is doing a lot right.
My point was intended to be more generic than just uutils though. Agreed that this specific project looks interesting.
And yes, I know the unsafe keyword is not inherently unsafe to use, but it’s also, in practice, one of the few potential footguns of the language, and is easy to abuse and get wrong. It’ll raise a few eyebrows in PRs and you’ll be expected to have both good reasons and a good test coverage at the very minimum lol. It’s a good red flag, if you do end up with runtime memory issues, that it’s probably happening in that block, but past this, you’re still basically foregoing some safety for convenience. And people fail. Often.
I know, but coreutils also literally never broke on me as they are. To me, the whole point of coreutils is that they’re just… there. I’ll leave the decision to change bundled tooling to distro maintainers.
I’ll also be perfectly honest: from a developer standpoint, end-users caring about the language a tool was developed with is, in the end, a pretty weird concept to me. Memory safety and cross platform compilation is DX stuff. Nothing tells you as a user that the thing you’re using isn’t sprinkling
unsafeeverywhere, in the end… The application itself doing what it advertises is what I’d expect most users to care about. Especially for stuff as old and relatively stable as most coreutils.Ah, except Electron. Fuck most Electron apps.
If you go to the uutils repo you can see that it’s making proper use of fuzzing, test, etc. and only makes use of unsafe in necessary areas. Uutils is also more consistent with modern standards thanks to
clap& uniform design, has out of the box selinux support, etc.The
unsafekeyword isn’t inherently “unsafe”, nore does it disable any checks contrary to what some believe.Also many distros are already packaging uutils do to it “growing into remarkably robust shape”, it’s just not ready to completely replace coreutils quite yet and so it’s not up for consideration by distros to ditch coreutils until it’s at least at parity. (That’s why I make use of hybrid and not outright replacing everything).
The point is not the language, it’s how the project is making use of the language and uutils is doing a lot right.
My point was intended to be more generic than just
uutilsthough. Agreed that this specific project looks interesting.And yes, I know the
unsafekeyword is not inherently unsafe to use, but it’s also, in practice, one of the few potential footguns of the language, and is easy to abuse and get wrong. It’ll raise a few eyebrows in PRs and you’ll be expected to have both good reasons and a good test coverage at the very minimum lol. It’s a good red flag, if you do end up with runtime memory issues, that it’s probably happening in that block, but past this, you’re still basically foregoing some safety for convenience. And people fail. Often.