One Makefile statement triggered a bug in rust ln:
src/%: @ln -sfn $(DIR)/foo src
In parallel build, we would get random failure: > ln: Already exists
Rewrote that Makefile to work-around it, and ended up with the same kind of bugs with parallel $(INSTALL) -D ...
Tried latest ubuntu 26.10 which supposedly fixes a lot of TOCTOU races in rust coreutils, but no better.
Gave up and switched back to original coreutils.
There's a whole load of basic bugs reported and ignored:
> Users of Ubuntu 24.04 LTS will be offered an automatic upgrade to 26.04.1 LTS via Update Manager a couple of weeks following this release after some planned backports to address regressions in a recent version of rust-coreutils.
https://discourse.ubuntu.com/t/ubuntu-26-04-1-lts-released/8...
The fix is still sitting unmerged many months later.
This surprised me since I thought the project was in heavy bugfix/compat mode. I won’t touch it until I see some velocity on open bugs.
Only half joking.
So the switching cost is buggy software. You'd need something radically different that brings enough new features to the table to make it worth it the switch and dealing with bad/non-existant support.
I think something like Nix/Guix but with stable library versions that matches Ubuntu/Debian LTS ones 1-to-1 could get traction
Everything just needs to run from a container with their expected runtime environment.
The apparently related bug in the origin project is https://github.com/uutils/coreutils/issues/2949, filed back in 2022 and which sat unmoved for several years until, probably not coincidentally, almost the same time yesterday that this appeared on Hacker News.
To get a response on a buggy GNU coreutils patch of theirs [1], I had to mention it in a rust-coreutils bug months later...
[1] https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/215...
Maybe the bugs get traction if you have a service contract?
Best to file bugs directly to upstream, but that of course means you should try it on the latest upstream version and not whatever version ubuntu ships, so it's more friction.
It will die so just leave it alone.
I haven't tried chromium but I presume it's the same issue.
At work I'm forced to use ubuntu and I placed snapd on hold and added mozilla's own apt repository to my configuration to get firefox.
At least in the past few months the dbus crashes (been using systemd on debian for several years just fine, this never happened) that render the system unusable and un-rebootable have stopped… I guess when my company will decide to upgrade to 26.04 there will be more instability and problems.
Flatpak uses shared stable runtimes that are the same everywhere and don't take up space more than once. It also comes with a native update system and sandboxing. Snap is the same thing but worse.
IIRC Snap relies heavily on AppArmor for sandboxing, so on anything non-Ubuntu the sandboxing is non-existent.
8MB is pretty huge though; musl libc is famous for defaulting to much smaller per-thread stack size of 128KB (to avoid over-committing lots of memory when there are many threads - the main dev is really principled/opinionated on this topic, but again there are a few ways for applications to explicitly size their stacks as large as they need). Linux kernel threads get a bit less than 16KB!
function rm(node) {
for (const child of ls(node))
rm(child);
unlink(node);
}
[1] https://github.com/rust-lang/rust/issues/112788
[2] https://github.com/rust-lang/rust/issues/153827
By-default guaranteed tail calls really isn't rust's style, because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. If you want to guarantee that a call can't allocate a new stack frame you should have to say it.
But I can understand the preference for an explicit opt-in, to make clear that it is enforced and not assumed.
I'd argue that it's explicit - that's what a function call does and you don't have implicit function calls in rust.
> Seems the latter is a kind of compiler-level optimization, of which there are already many (I think) that change the semantics internally but guarantee the outward behavior stays the same.
What you're asking for here already exists. Tail calls might be optimized into not allocating extra stack frames, the rust compiler just doesn't guarantee that it will perform that optimization (and almost certainly won't when code is compiled without optimizations... for instance).
What people want is the semantic guarantee that the stack frame won't be allocated. Not just a compiler that often performs the optimization. Otherwise you can't be sure that your code will keep working with new compiler flags/versions/architectures/... You could say "whenever the code is the right shape we'll guarantee the optimization" (C++ famously did this for things like copy elision)... but now the shape of code comes with non-obvious semantic guarantees and that's not rust's style. Hence the proposal for a keyword instead.
No, it won't change semantics - if you say @musttail or similar, it will simply fail to compile if you, say, introduce a destructor - the semantics will not subtly change.
The whole idea of "let's change semantics to make it easier" is dumb.
If you want guaranteed tail calls, change your code until it works.
For recursion only kotlin.
(For most of these only with syntax specifying it)
Using recursion on unbounded inputs on a programming language that doesn't support that (which are most) is an extremely classical mistake that really should be known to all programmers, especially those of low level languages that care about safety.
Every time you call something recursively you should be thinking "how deep is this?".
Incidentally someone submitted a PR for this issue about 3 hours before the first comment about it in this thread - https://github.com/uutils/coreutils/pull/14554 (and 2 hours before this link was submitted to HN)
That's also not all that's happening. It's also making improvements like better internalization support, better error messages, and a small handful of other extensions.
Why is that? The tests are not linked to the distributed binaries. You can also distribute project sources with mixed licenses.