It's not Rust, it's FreeBSD (and LLVM) (opens in new tab)

There's ongoing debate in the Linux community about the use of Rust in the Linux kernel (e.g. wrapping existing APIs safely for driver development). This heated up recently. Use of Rust puts requirements on the kernel developers to specify a Rust compiler version to use and ensure C code changes do not break Rust code and vice versa. This has triggered discussions in other communities.

The linked discussion is amongst FreeBSD developers about how to conceptualize FreeBSD itself (where compilers, kernel, userspace and ported application code lives) and where compilers like Rust fit into that vision in the future. Unlike Linux, which is just a kernel, FreeBSD is a kernel + userspace + compiler (equivalent to the GNU part of GNU/Linux + GCC or LLVM).

See the TL;DR available in the last paragraph.

Historically a (Free-)BSD operating system is a single repository of source code that is self-hosting (kernel and userland including compilers). Commercial UNIX vendors loved to double dip by withholding the toolchain (that initially came with their AT&T tapes) and having customers pay extra for that part.

While BSDs included quite a lot of base system tools for the time e.g. a default DNS, SMTP, and HTTP server. OpenBSD contains their own forked X11 server and basic GUI tools, but FreeBSD reduced the base system over time. Most of the evicted code wasn't discarded, but mover into the FreeBSD ports tree. The ports tree is the collection of build instruction for software outside the FreeBSD source repository. These ports are compiled into binary packages for the FreeBSD package manager pkg (sometimes called pkgng). Just like the Klingons of TNG we prefer not to talk about the old pkg_ package manager that came before.

So FreeBSD is split into the base system installed during initial installation and kept up to date by freebsd-update or by compiling from source if you want to deeply customise your system or develop FreeBSD itself.

For almost a decade there have been efforts by a few FreeBSD developers and users to enable the use of the package manager for the FreeBSD operating system itself. The old release tools produced just a handful of tarballs while the package base tooling partitions the system into 400-500 small packages. Starting with FreeBSD 14.0 package base is officially supported even if it's not exposed in the menu driven installer (yet).

Now that it's feasible to have all software present on your FreeBSD system be installed by the package manager. In this configuration there is no friction installing or *not* installing base on if it's part of the FreeBSD source repository or a port in the ports tree.

Installing additional software from ports has always been possible, but omitting parts of the base system used to involve writing a make.conf, compiling the system yourself, and either installing and updating from the compiled sources or producing your own release images and running your own freebsd-update server. So while it has been possible to subset FreeBSD for decades few users cared enough about the on disk size of their FreeBSD installations to bother with this.

With the conclusion of package base it's now easy to trim down FreeBSD installations e.g. not install the debug symbols, compiler toolchain, test suite, a few other seldom used larger tools. The difference is massive in relative terms (e.g. ~100MiB vs. ~4GiB) and you can still install the packages while you to debug a problem.

Some FreeBSD port maintainers worry that their workload will increase. Either from users choosing to remove essential components from the operating system installation and incorrectly blaming the software impacted. Right now there is also no infrastructure in the FreeBSD ports tree for a port to specify which parts of the base system is required by a port as a runtime dependency recorded in the resulting package. Unless the package manager is extended to understand that base dependencies on base system packages are a special case such packages could also only be installed on system using packages to manage the base operating system installation.

Almost every FreeBSD installation in use will already have some packages installed: the package manager itself, a more modern shell (zsh, bash, etc.), developers will need git and users will install some set of services that as the reason they're even running the machine.

When it comes to LLVM: it's the system compiler toolchain. It's required to build FreeBSD, but not to run it (ignoring the C++ runtime library). Moving it from the base system into the ports tree would reduce FreeBSD (clean) build times a lot. At the same time the resulting operating system would no longer be self-hosting by some definitions of the term. The packages in a FreeBSD binary package repository are supposed to be compatible with all minor releases (that aren't end-of-life) within the same major release line (e.g. there is one repository for FreeBSD 14 and the packages contained in it must work on 14.0 and 14.1). The overlapping support windows of minor releases in the same major release line would otherwise effectively prevent upgrading the system compiler.

Finally lets look at the immediate consequences of accepting Rust code into FreeBSD itself instead. In my opinion this can best be estimated by looking a the fallout from commonly used libraries available through the ports tree starting to use Rust (e.g. librsvg). Building LLVM and clang is already bad enough, but a C and C++ compiler aren't negotiable for building any *BSD system. The rustc compiler is even slower to build then clang and unless the build system scales perfectly and you have enough spare cores and memory bandwidth to burn its build time comes mostly on top of the existing build time. As soon as essential parts of the operating system depend on anything written in Rust bootstrapping (or worse porting) its the Rust toolchain would also be a new burden on anyone wanting to bring up FreeBSD on a new architecture (e.g. RISC-V or CHERI). The FreeBSD base system would now also depend on a specific Rust version which will become a problem for the ports tree to bring a newer compiler to older releases to port new software to older, but still supported, releases.

TL;DR: Any benefit from evicting LLVM and clang out of the FreeBSD source repository would also apply to rustc. If done well this would mitigate most of the workflow problems by waiting for bloated compilers to build themselves. The merits of depending on an additional language and rewriting existing code in it aren't FreeBSD specific.

FreeBSD has always been able to self-host (build the itself from source) with just whats available in the FreeBSD src repository. To do this it needs a toolchain that includes among other things a linker, an assembler, and a C and C++ compiler. This used to be GCC, but GCC was replaced with clang which is a C and C++ frontend for LLVM. Just sticking to the last GCC 4.x release under GPLv2 forever wasn't an option and neither was importing a GPLv3 toolchain. Clang also brought some welcome advantages (it used to provide a lot more useful and human readable error messages, better code analysis tools to catch common bugs).

The reasons you have different versions of LLVM in the ports tree is that users either directly require a specific version or other ports require a specific LLVM version as a dependency (e.g. compilers for Rust, Haskell, Julia, etc.). There will never be a situation where every user and every port is happy at the same time with just one LLVM version, because LLVM isn't just the compiler frontends, but also the C++ libraries used to implement compilers and API changes with each release.

And even if the compilers available in the ports tree using LLVM as their code generation backend could be patched to build with the latest version, which would already be an unreasonable demand on their port maintainers. The new LLVM release may add new optimisations that are "legal" to a language lawyering compiler writer according to their understanding of the LLVM IR semantics, but still break existing code by exploiting undefined, under defined, or implementation specific behaviour.

The problem with moving the system compiler out of the ports goes deeper than just the self hosting aspect. The binary package repositories compiled from the ports tree must work for all still supported minor releases on that major release line (e.g. https://pkg.freebsd.org/FreeBSD:14:amd64/latest/ works for both 14.0 and 14.1). Given that the supported lifetimes of minor releases in a major release line overlap and that compilers don't provide perfect binary compatibility this would lock in the compiler for the whole major release to whatever was packaged for the .0 release. Do you want to be restricted to C and C++ language version and instruction set support from 5 years ago by the end of a major release line? Stuck dealing with compiler bugs that have been fixed ages ago, but never backported?

I would like to see full support for external toolchains from ports before anyone dares to evict the compilers from the base system even if LLVM is a bloated enough to dominate the build time and install size.

Because the compiler in base necessarily has the same life cycle as base, while ports lets you rotate new versions in whenever you want.

Hasn't LLVM solved their license requirements already (at the cost of removing some niche CPU targets)?

I'm using package base on FreeBSD 14.0 and 14.1. Upgrading the system worked as expected.

FreeBSD already has a documented official way to deal with ABI breakages. You're supposed to install the new kernel only, reboot, install rest of the new release (including updating /etc) and reboot again. Next upgrade the installed ports/packages. Afterward delete the old files (and libraries) and reboot again.

Upgrading/reinstalling all installed packages during the userland upgrade after the first reboot takes care of that on a package base installation whenever the ABI triple changes. If you're using ZFS boot environments they provide an even faster and safer way to upgrade without rebooting in between steps by creating a new boot environment from the currently active one, mounting it as a jail (or chroot env) and pointing the package manager at the mountpoint.

Neither OpenBSD nor FreeBSD are still commonly used without at least one binary package installed so the complexity of having a package manager that works isn't optional.