From nobody Sun Aug 04 17:55:26 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WcS0Y63D5z5Sl9P for ; Sun, 04 Aug 2024 17:55:41 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WcS0X4Mm1z4GXN for ; Sun, 4 Aug 2024 17:55:40 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.181 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-oi1-f181.google.com with SMTP id 5614622812f47-3daf0e73a5bso6736003b6e.0 for ; Sun, 04 Aug 2024 10:55:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722794138; x=1723398938; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KxSIRVRW/ZpoIf8iKWngQZtYPj8n0+B+0okMCK9WXMg=; b=GprXuOgNg7ofjb+2LyZI7zH+71ch8g3HcSSQqbwNW5YRTumFFAL2LhPD1DRTJEd1Aw 9MuTi+O4fEmx61H+8pXClGdvmnqxJbvYwG10LPSqg+Cq1QDDSr/X39vF08LX9QQM5fp7 MN2oQOuy+Wi79wsKe04fnZ6+a/fzJObsK7lO0NqRSjxrDf7wQJ/UGqWzaMuEDoKIPsGP SP7yF7NPNpfQAcMWGCs0Z8/ySz3dUIO+fxTVwtCEgxVWiTcFjhVR9wbHJN/Z9XDN4mgj JDgY1mpiMKmxG3gDSifXO5vXhRAJUTgNvm4all6KgqqDwU6PMjlb/Z04FsXPK26G7/tK GSzw== X-Gm-Message-State: AOJu0Yx4STT4IHxuLN0Ge8vPmK7+tYF/pRIfp1+Vlp44NXOvTb3xAg6z ujJNbUlE69e57bbOlnYnf+Z80nXxcpvt8i9bNUytIyR25YRty8CEpRmZMi829AdyK7K720ooWst M0V4ZayIsiNQCrKATK9G2Uv9J9gH1/eE4 X-Google-Smtp-Source: AGHT+IHqnlqfOEiAmxV1qq6r002h138qDojeqz+N15B6vWh7JnGcUn0TEn7CpGLKS9WAvMoE3ZVJk5mnQsVAlLqk6Rs= X-Received: by 2002:a05:6358:5283:b0:1a8:b83a:8e26 with SMTP id e5c5f4694b2df-1af3b946fc2mr1104706055d.0.1722794138129; Sun, 04 Aug 2024 10:55:38 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 From: Alan Somers Date: Sun, 4 Aug 2024 11:55:26 -0600 Message-ID: Subject: A Demo of rust-in-base To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.86 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.962]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.181:from]; TO_DOM_EQ_FROM_DOM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.181:from] X-Rspamd-Queue-Id: 4WcS0X4Mm1z4GXN 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