Date: Sun, 4 Aug 2024 11:55:26 -0600 From: Alan Somers <asomers@freebsd.org> To: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: A Demo of rust-in-base Message-ID: <CAOtMX2gdt8xYyLR3peYWhov-161-6d7%2B8L6TiHCCyw1NQyspXw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Due to all of the recent discussion of using Rust for code in the FreeBSD base, I've put together a demo of what it might look like. It demonstrates: * Interspersing Rust crates through the tree (usr.bin/nfs-exporter, cddl/usr.bin/ztop, etc) rather than in some special directory. * Build integration for all Rust crates. You can build them all with a single "cargo build" command from the top level, and test them all with a single "cargo test". * Wholly new programs written from scratch in Rust (ztop plus three Prometheus exporters) * Old programs rewritten in Rust with substantial new features (gstat and fsx) * Libs (freebsd-libgeom and freebsd-libgeom-sys) * Commits that reconcile the dependencies of multiple crates, so as to minimize duplicate dependency versions (5764fb383d4 and 1edf2e19e50) * Vendoring all dependencies, direct and transitive, to ensure internet-independent and reproducible builds (37ef9ffb6a6). This process is automated and requires almost no manual effort. Note: don't panic if you look in the "vendor" directory and see a bunch of crates with "windows" in the name. They're all just empty stubs. * All Rust object files get stored in the "target" directory rather than /usr/obj. Today, if you want them to be stored in /usr/obj the best way is to use a symlink, though there's WIP to add MAKEOBJDIRPREFIX-like functionality to Cargo. It does NOT demonstrate: * Integrating the Rust build system with Make. Warner has some ideas about how to do that. * Pulling rustc into contrib. This tree requires an external Rust toolchain. * Building any cdylib libraries with Rust. That's useful if you want a C program to call a Rust library, but I don't have any good examples for it. * kernel modules. As already discussed, those are hard. * Any Rust crates that involve private APIs, like CTL stuff. Those are among the most tantalizing programs to move from ports to base, but nobody's written any yet, because Rust-in-base doesn't exist yet. Also, I want to address a question that's popped up a few times: backwards-compatibility. There is a fear that Rust code needs to be updated for each new toolchain release. But that's not true. It hasn't been true for most crates since Rust 1.0 was released about a decade ago. A few exotic crates required "nightly" features after that, but they are very few in number these days, and none of them are included in this branch's vendored sources. What Rust _does_ do is it releases a new toolchain about every six weeks. Each new release typically includes a few new features in the standard library and they often add more compiler warnings, too. Sometimes they include wholly new compiler features, but they are _always_ backwards compatible with existing syntax. Roughly every three years, Rust publishes a new "Edition". Rust Editions are very similar to C++ versions. i.e. Rust 2018 is to Rust 2021 as C++14 is to C++17. New editions can include backwards-incompatible syntax changes, but each crate always knows which Edition it uses. Crates of different Editions can be linked together in the same build. This branch, for example, contains crates using Editions 2015, 2018, and 2021. If you have any questions about what Rust in Base would look like, please examine this branch. And if you've never used Rust before, I highly encourage you to try it. It really is the best new systems-program language for decades. IMHO, it's the only one that's a compelling replacement for C++ in all new applications, and C in most. https://github.com/asomers/freebsd-src/tree/rust-in-base-demo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2gdt8xYyLR3peYWhov-161-6d7%2B8L6TiHCCyw1NQyspXw>