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 an

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.