From nobody Tue Jan 23 07:48:08 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 4TJzj75KR9z57VYm for ; Tue, 23 Jan 2024 07:48:11 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TJzj74MXnz4nnG; Tue, 23 Jan 2024 07:48:11 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705996091; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MzCQuiPA7dDo4MhJ8vzDTSKU3o6pPUdxGyAViFmvS5A=; b=hLT+mD1JaHPriNg6Nkro2sbXj4/8ngp5xCqW+lmXgUbhi/wnJCt3BHUd//DMl7dkHPEiYp uyVhq5mCpokYQoYTwQPpehz4k/+ogkpDZWoZHOA6P1nmPYR+BhRZa1QwjDwiWvP+Li3nk8 uyi75tN9yLAUwAjGWFR5EunVoJ0Efllq1EJ32LWty9TX9QvAwpfmypDsWrnUqVMiH03HRR Eh8BHTxsOynvxzBTaoZKjrTRPhC3yovEL5WvLMQuQpX2e5cvTIjgFwtH13inl0BO16I1nT JDzIY5d/SVpo1Hf5e5jblTWsx+ubkilzTzyMykpvl7HmdU3d1XqpNjVlLiE2nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1705996091; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MzCQuiPA7dDo4MhJ8vzDTSKU3o6pPUdxGyAViFmvS5A=; b=c/4HLbkMEuarDUH26jUcB493tpbaFVYniWm04CEZ65Q1lanmRe/R+F7YWtpLezLg8wHOpw AemqOnmQ1jJGsSAFf0HJ54cYgHWwaqA+Otu9YwWny55MB+4H1gjxVsDaJuKLdr7UgpLaf1 h+exBaLAWeeu8a/k498hM8Tsz2hlEJAZ3UX9rQ112++x+gSMnUQi3RRziP/Sc6RWKFyO8C gzqDLJkkaoA/Wr74HpBP81O3WDr1gFCbmg+jg6dcvdZDjdt3ga4IvxFHHc/kAtxNkDjbjg 204ejDDPwaBzaJNDbUH0fCSF+SXpavaxYKcR9mFgAqk0T8hqrlLA0KvoSQ5z1A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1705996091; a=rsa-sha256; cv=none; b=O/xg7Jk5R/6FnpdX3OuDKq2cHeFYGITtkJ2S0LxmV8Oro45pK/fF/mmLJDDPz25+uGfrvE phvGHAs+3si8MKm+JiF2KLSFI9YQA69Yp22Yhw0GgJGLCGllGZJGuiO8iO464mnnfaAamU bQMxzHfAnDTt/ejXz1/jWGYDIKgI/iUj5EFTm7QQccdZC1bbaKuwxxe150927AMIE4RFn2 8UzPnsTtosvrelunpKoHxt//+Y2lXk3vjVGxaQZGMhfjjtYawc3wUmUwsDz0CW9Br1FtdG QAgtNkufIdG38aAdt+JtS5OzETK5PrU7e5m/ubeSBv3TH7keRweU1+pSOwuczQ== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TJzj71vc0z1CLW; Tue, 23 Jan 2024 07:48:11 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 07F4912A7BF; Tue, 23 Jan 2024 08:48:09 +0100 (CET) Date: Tue, 23 Jan 2024 08:48:08 +0100 From: Baptiste Daroussin To: "Robert R. Russell" Cc: freebsd-hackers@freebsd.org Subject: Re: Re: The Case for Rust (in the base system) Message-ID: References: <1673801705774097@mail.yandex.ru> <202401210751.40L7pWEF011188@critter.freebsd.dk> <20240121171403.6f167408@venus.private.rrbrussell.com> <202401220857.40M8vlHr099146@critter.freebsd.dk> <20240122173344.516be9d8@venus.private.rrbrussell.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240122173344.516be9d8@venus.private.rrbrussell.com> On Mon, Jan 22, 2024 at 05:33:44PM -0600, Robert R. Russell wrote: > On Mon, 22 Jan 2024 08:57:47 +0000 > "Poul-Henning Kamp" wrote: > > > 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 ? > > > > First thank you for the reasoned response. Second the project probably > needs a discussion about the build system and can the compiler be moved > to ports. I think that is off topic for this thread. > > Looking back at my own Rust code, We appear have come to similar > conclusions about Crates.io value. SERDE in particular has become one > dependency I try to avoid at all cost. > > Which I think leads to one of my big reasons for supporting Rust and > something else that needs to be moved to its own thread, Text encoding > issues. I think the project needs to follow OpenBSD's lead and > deprecate non UTF-8 locales. While I personally can't read or write > anything other than English and a few dozen words in Spanish, > Portuguese, and French, I can find or create test input data that isn't > in basic ASCII and test my string handling against such input. Assuming > allowing things like French column names make sense. First this is already deprecated, only utf-8 locales and encoding are being updated on regular basis! Second, no we will not follow the path of OpenBSD here because locales are not only for interactive, but text processing, like for example databases (collation, comparison etc) and there are plenty of data stored that cannot be converted to unicode for many valid reason, dropping non unicode locales will just make sure those data and databases cannot be served on FreeBSD anymore! (btw note that OpenBSD, while having deprecated all non UTF-8 encoding support, do not support unicode collation). Best regards, Bapt