Microsoft ships Rust coreutils for Windows — and it's not uutils

4 min read 1 source clear_take
├── "Microsoft chose to build its own coreutils rather than fork uutils because Windows is the design center, not POSIX"
│  └── top10.dev editorial (top10.dev) → read below

The editorial argues that uutils is optimized around passing the GNU test suite, while Microsoft needs first-class handling of NTFS junctions, alternate data streams, ACLs, UNC paths, and PowerShell object pipelines. A cp that correctly handles NTFS reparse points is fundamentally a different program than one targeting POSIX symlinks, which justifies a structurally distinct codebase even under the same MIT license.

├── "This is the unmistakable trajectory of Microsoft rewriting Windows userland in Rust, no longer a hedged evaluation"
│  └── top10.dev editorial (top10.dev) → read below

The editorial frames coreutils as Microsoft's third Rust beachhead inside Windows, following the BlueHat 2023 kernel work and the open-sourced Edit text editor earlier this year. The pattern of public, incremental rewrites contradicts years of official 'we're evaluating Rust' messaging and signals a deliberate, ongoing migration of Windows userland to Rust.

└── "Surfacing the repo as notable signals community interest in a Windows-native POSIX toolbox"
  └── @gigel82 (Hacker News, 180 pts) → view

By submitting the bare microsoft/coreutils repo to Hacker News and driving it to 180 points and 170 comments, gigel82 implicitly positions this as a significant event worth the community's attention. The strong engagement suggests developers see value in Microsoft owning a Windows-first POSIX toolbox rather than relying on WSL, Git Bash, or third-party ports.

What happened

Microsoft quietly pushed a new repository to its GitHub org: [microsoft/coreutils](https://github.com/microsoft/coreutils). It is a Rust implementation of the GNU coreutils — `ls`, `cat`, `cp`, `mv`, `rm`, `wc`, `sort`, `uniq`, the whole POSIX toolbox — targeted at Windows as a first-class platform rather than a Unix afterthought.

The interesting part isn't that it exists. It's that Microsoft chose not to wrap or fork [uutils/coreutils](https://github.com/uutils/coreutils), the established Rust rewrite that Canonical has been quietly preparing to ship in Ubuntu 25.10. Instead, Redmond started a new tree. The README is sparse, the commit history is fresh, and the license is MIT — same as uutils, but the codebase is structurally distinct.

This is Microsoft's third Rust beachhead inside Windows, after the kernel work announced at BlueHat 2023 and the open-sourced Edit text editor earlier this year — the trajectory is no longer ambiguous. The official line for years has been "we're evaluating Rust for systems code." The actions say something less hedged: the userland is being rewritten, in public, one utility at a time.

Why it matters

The obvious question is why Microsoft didn't just adopt uutils. The uutils project is mature, has hundreds of contributors, passes most of the GNU test suite, and is already the default in NixOS configurations and a flag away in Debian. Forking it would have been the path of least resistance.

The most credible read is platform ownership. Uutils' design center is POSIX compatibility — the GNU test suite is the north star. Microsoft's design center is Windows: NTFS junctions, alternate data streams, ACLs that don't map cleanly to chmod, PowerShell pipelines that move objects rather than bytes, and UNC paths with backslash separators that break every regex written by a Linux developer. A `cp` that handles NTFS reparse points correctly is a different program than a `cp` that handles symlinks correctly, even when 95% of the code is shared. Owning the tree means Microsoft can prioritize those edge cases without negotiating with upstream.

The second read is supply chain. Coreutils ship in-box on every Linux distribution, which means they are part of the trusted computing base. If Microsoft eventually bundles these binaries with Windows — and the repo's existence inside the `microsoft/` org strongly suggests that's the plan — they need provenance they fully control. A Microsoft-signed `ls.exe` built from a Microsoft-owned Rust tree is a different audit story than a binary built from a community project, no matter how well-run that community is.

The community reaction on Hacker News split predictably. One camp sees fragmentation: two Rust coreutils competing for contributor attention, with the inevitable subtle behavioral divergence that will bite anyone trying to write portable shell scripts. The other camp points out that GNU coreutils and BusyBox have coexisted for two decades with documented differences, and the world hasn't ended. The realistic outcome is a third dialect of `ls --color` flag handling that you'll need to remember when your CI runs on a Windows GitHub Actions runner.

There's also a quiet political subtext. The Rust-for-Linux project has been the highest-profile Rust-in-systems story for years, with all the maintainer drama that implies. Microsoft is doing the same work without the public flame wars, because it owns the tree and ships the kernel. That's not a moral judgment — it's an observation about who can move faster when there's no consensus to negotiate.

What this means for your stack

If you maintain cross-platform tooling, the practical implication is that the "Windows is weird" tax on shell scripting is about to drop. Today, a Node.js postinstall script that calls `cp -r` works on macOS and Linux and explodes on Windows unless you've installed Git Bash, WSL, or a `cross-env`-style shim. When Microsoft ships these binaries in-box, the same script will work on a vanilla Windows box without telling users to install a Unix environment first. That's a real win for the Node, Python, and Go toolchains that have been papering over this gap for fifteen years.

For people maintaining CI matrices, expect a transition period where you'll need to detect whether you're hitting GNU coreutils, BusyBox, uutils, or Microsoft's coreutils, and adjust expectations accordingly. The flag surface is largely compatible but the edge cases — `ls` quoting, `sort -V` semantics, `cp --reflink` on copy-on-write filesystems — will diverge. Add a `coreutils --version` check to your build scripts now; you'll thank yourself in eighteen months.

For anyone working on developer tooling that targets Windows, this is also a strong signal that Rust is the supported path for new in-box utilities. If you've been waiting for Microsoft to bless a systems language for cross-platform CLI work, the answer has been telegraphed. Ship the Rust binary, statically link, accept the larger artifact size, move on.

Looking ahead

The interesting test is what happens to uutils. The project has been positioned as the inevitable POSIX coreutils replacement, with Canonical's Ubuntu 25.10 ship as the proof point. Microsoft's parallel effort either becomes a healthy second implementation that keeps uutils honest, or it becomes the de facto Windows standard and uutils stays Linux-flavored — at which point we've reinvented the GNU/BSD split with Rust syntax. Either way, the era of "there is one coreutils" ended quietly this week, and the next twelve months of Rust-systems gossip just got more interesting.

Hacker News 180 pts 170 comments

Coreutils for Windows

→ read on Hacker News

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.