Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch.
But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:
@xerz@lcamtuf it’s easy to fall for domain specific knowledge traps when you’re learning which is why it’s often advised against rewriting software from scratch, especially if you were not in the first team of developers
@hypha@xerz@lcamtuf tbf i think the framing that "they shouldn't have" is wrong and bad. *canonical* should not have switched, because that is such a bad idea
@xerz@star@hypha@lcamtuf Switching to dependencies with a single non-replaceable toolchain is also irresponsible.
Core utilities should not rely on something that can believably be slopped into oblivion with no viable replacement (C compilers are a dime a dozen and comparatively much easier to implement, with many functional replacements readily available).
Proper specification of all the core toolchains should be a bare minimum.
@xerz@hypha@star@lcamtuf Last I had heard from gccrust is that it couldn't even be used for bootstrap compiling yet, without enforcing any of the semantics a Rust compiler is expected to.
It's unclear whether it also now does that as of this progress report or not. If it does then that would be progress indeed.
@lispi314@xerz@hypha@lcamtuf you don't need borrow checking in well-formed programs. You need borrow checking to ensure a program is safe. the rust compiler is currently the definition of what is well-formed so you don't really have an advantage if you compile the 1.49 sources with or without borrow checking
