Alan Somers
2024-08-04 17:55:26 UTC
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
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
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
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de