What does HackerNews think of coreutils?
Cross-platform Rust rewrite of the GNU coreutils
Adding other tiers is welcomed. Take a look at the supported platforms (https://doc.rust-lang.org/nightly/rustc/platform-support.htm...) and see if there's a platform you'd like to target that isn't a tier 3 target at least. There's HaikuOS, PlayStation1 etc. I'm on a Tier 2 platform myself and I'm really happy.
If you'd like even more platforms, there's an ongoing project to add a GCC backend to rustc (https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-20).
> if it can make all the existing code written in that language suddenly available for the new platform, that platform instantly becomes orders of magnitude more useful and powerful.
I agree with this, but creating a front end that can actually compile all existing code correctly is a massive task. If the compiler is modular enough, you should be able to contribute just a backend, rather than reimplementing a frontend. I'm strongly against only the frontend reimplementation, because it's no longer clear what "valid" Rust code is.
In summary - I completely agree with the importance of targeting niche platforms. I think supporting multiple backends (LLVM now, libgccjit and Cranelift in future) gets us there without fracturing the ecosystem.
> but easier than having to reimplement a whole userland from scratch.
Probably. But once it's reimplemented (https://github.com/uutils/coreutils) I think it's really cool you can run get binaries for Linux, macOS and Windows with one build command.
I love these re-implementations of things. Technology advances by the continued reinvention of the wheel, and even if some efforts end up being of merely didactic interest, it is still important to make them. Coreutils is one of the pillars of our civilization, and thus it should be re-implemented several times on many programming languages.
Looking at the source code, it is impressive that this re-implementation is essentially complete! Look at this: https://github.com/uutils/coreutils/tree/main/src/uu It's only missing some obscure and fringe things.
An important feature of GNU coreutils is, somewhat sadly, not reproduced by this re-implementation: the copyleft license of the original implementation. This takes out some freedom of the users. For example, when I use GNU "ls", I know that I can always look at its source code and change it to my whim (or hire a programmer to change it for me). However, if I use uutils "ls", this is not necessarily the case, for it may be a re-distribution by some middle-men that has modified it slightly and does not provide the source code. I suppose that the removal of this freedom is accidental, because it was a nice thing.
I was a big fan of FSF until that point.
They are, though. Like, I don't even disagree with the cost of rewriting, but there are very much active efforts to rewrite things in rust (ex. coreutils - https://github.com/uutils/coreutils , OS - https://www.redox-os.org/ ) or to add rust to existing projects (Linux, Firefox and Chrome both (https://chromium.googlesource.com/chromium/src/+/refs/heads/...)).
https://github.com/uutils/coreutils ("Cross-platform Rust rewrite of the GNU coreutils")
> tldr: Rust/coreutils ( https://github.com/uutils/coreutils/ ) is now available in Debian, good enough to boot a Debian with GNOME, install the top 1000 packages, build Firefox, the Linux Kernel and LLVM/Clang.
Rewrites in general are usually a terrible idea, unless the original is horribly broken (and beyond fixable).
If you wrote your app in C++, instead of rewriting it for the next decade in Rust just to get to the same point, slap some AddressSanitizer, ThreadSanitizer, -fanalyzer, cppcheck, etc. on it. You will get 98% of the way there.
Instead of spending 8+ years(!) rewriting[1] the GNU coreutils in Rust, you could spend half that time to ensure full coverage (branch-coverage, condition-coverage) in the existing ones. I will actually have a breakdown if someone tries to rewrite SQLite in Rust[2].
1: https://github.com/uutils/coreutils 2: https://sqlite.org/testing.html
I definitely can understand the fatigue with "rewrite it in Rust" though, as there is a lot of that.
Something you might be interested in is that people have actually gone through the effort of rewriting the actual coreutils to spec in Rust (https://github.com/uutils/coreutils).
Is it just my version of Firefox, or does anybody else get a line wrapping justification algo that ends the first line with "Debia" and begins the next line with "n"?
It appears hyperlinks are split opportunistically to match the line justification.
Two things:
* I have never seen a single web page do this
* Something smells soooo right that the only page I've ever seen with this weirdo readability regression involves the word "Debian." It's as if when I read the word "Debian" in a blog/article, I get this sixth sense shiver that something soon will be broken with a default setting because "nobody ever said you couldn't do it the other way."
Edit: it's as if this choice were made specifically to keep me from clicking the FF Reader button. Because now I'm scanning over the entire document counting the number of words in hyperlinks that are broken across lines-- I see 8, which includes another instance of "Debian"-- this time it's broken into "D" and "ebian."
Edit2: OMG the text doesn't wrap to remain in the viewport when I zoom in. I successfully see "Debia" at the end of the first line every time, and if I zoom in far enough I can enter horizontal scrollbar readability hell.
> Why?
> Many GNU, Linux and other utilities are useful, and obviously some effort has been spent in the past to port them to Windows. However, those projects are either old and abandoned, are hosted on CVS (which makes it more difficult for new contributors to contribute to them), are written in platform-specific C, or suffer from other issues.
> Rust provides a good, platform-agnostic way of writing systems utilities that are easy to compile anywhere, and this is as good a way as any to try and learn it.
In general there has been more effort put into trying to improve on the default tools through projects like ripgrep (grep), bat (cat), lsd and exa (ls), and fd (find) rather than creating drop-in replacements that don't provide all that much over the battle tested originals.
The only reason he might still be right is if they don't aim to be POSIX-compliant. The page doesn't explicitly call out compliance as a goal, but given that it has some busybox tests, it's probably compliant or very close.
This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust (https://github.com/uutils/coreutils).
More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekeeping implied here (it's not a serious language because it's not used to build an operating system) is really toxic. Especially considering that the gate in question has already been thoroughly breached by the language in question (some universities have switched to using Rust in their OS courses, for example).
commit d4e96b33e343733992fad55ac840c9649cd72ede
Author: Jordi Boggiano
Date: Fri Aug 2 09:22:57 2013 -0700
Initial commit