Date: Mon, 22 Jan 2024 08:57:47 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Robert R. Russell" <robert@rrbrussell.com> Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: <202401220857.40M8vlHr099146@critter.freebsd.dk> In-Reply-To: <20240121171403.6f167408@venus.private.rrbrussell.com> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <1673801705774097@mail.yandex.ru> <CANCZdfpqWgvV_RCvVO_pvTrmajQFspW%2BQ9TM_Ok3JrXZAfeAfA@mail.gmail.com> <ef4ad207-5899-42b6-8728-bc46f1417e9e@antonovs.family> <202401210751.40L7pWEF011188@critter.freebsd.dk> <20240121171403.6f167408@venus.private.rrbrussell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert R. Russell writes: > How do you define all the cool kids are doing it language versus I am > assuming a serious language? I am not being sarcastic. That is a fair and valid question. My comment was not so much about the language itself, as about the arguments tendered for why we should import it in FreeBSD. Let me fold that out, so we have it in the mail-archive for future use: Rust has certainly been around for long enough to be taken seriously, but so has FORTH, C++, Perl, Tcl, Modula-3, Haskell and Lua, all of which have at one time or another, tried to wiggle their way into FreeBSD-src, with very different outcomes. FORTH is still here, because the loader uses it. The loader used to be incredibly size-constrained, so FORTH was almost the only option we had, but that is much less of an issue now, and Lua is eating into the loader, because one can actually read Lua code. (I personally love FORTH, but RPN is not for everybody.) C++ is still here. It got in because it sort-of came for free with GCC and we needed it for groff to read our manual pages. These days groff is gone, but now CLANG uses C++, so it stays. The maintenance load is very small compared to the load carried. Perl got in, and got thrown out again, when we saw how much pain it caused. Partly because the situation with perl-modules where very similar to what people say about Rust crates, but also because the language was so rapidly evolving, that we would never be able to ship an acceptably up to date version in our releases. As I remember it, Tcl never got in, despite me pushing heavily for it, and today I will agree that Lua does the "embedded language" thing much better. Modula-3 had one thing going for it: CVSUP, but even though that was for the project what git(1) is for us today, that wasn't enough. In fairness I should say that the maintenance would have been very heavy because of the posix-incompatible threading. Haskell barely got any discussion, as I remember it, the arguments were nowhere near credible. Lua had a strong use-case, came with a good proof-of-concept code and a very small maintenance footprint. You literally cannot tell that it isn't just "another library". To me Rust lands somewhere in the cursed triangle between C++, Perl and Modula-3. Rust's rapid release-cycle means that we will have to deliver the built-in Rust in such away that the users can install a newer Rust from ports, or directly, without friction. As far as I can tell, Rust is no better prepared for that than Perl was, and the Rust Crates equally not so, like the Perl Modules. At the very least, that means serious maintenance work for us, and we will probably still annoy the actual users of Rust. With Perl we ended up have a special magic "only for use in the tree" Perl, and if people wanted to use Perl in any other way, they had to install another Perl from ports. Then there is the "There's always a Crate for that..." attitude, which we also saw with Perl: We received numerous "Perl in base is useless unless we also import at least the following N Perl Modules" for a very large union of Ns. Fundamentally there is a huge difference between importing a programming language, which we have done successfully, and importing an eco-system, which we tried once and ran screaming back. Even ports, which is laser-focused on 3rd-party software, is having some impedance trouble with eco-systems. But it could still make sense for us, if we decide to go all-in, the way for instance Mozilla has chosen to do: If most of userland ended up being Rust programs, the amortized maintenance hazzle might be worth it. But I dont see that happening: The testing and validation that we got all (mis-)features to be (bug-)compatible would be an utter waste of time, and who would care if paste(1) is written in C or Rust anyway ? If we do not go all-in, Rust needs a "killer-application", and as you have probably spotted already, my "rewrite CVSUP" was not just a flippant thought: If CVSUP was not enought to get Modula-3 over the line, Rust will have to do better. If people want Rust in FreeBSD, their first task is to show, with actual code, how much better it would make FreeBSD, and I saw nothing like that in the email thread, and thus the "all the cool kids use it" summary. I know that we in the Varnish project love our "varnishtest" to pieces, it has made us so much more productive, but I dont know if a "freebsdtest" program, written in Rust or any other language, would become the same kind of success. Poul-Henning PS: And to take this to it's logical conclusion: Apart from tradition, I'm not sure I see why we have a C-compiler in the tree anymore. Wouldn't everybody's life be easier if we just used a compiler from ports ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202401220857.40M8vlHr099146>