Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Jan 2024 15:35:30 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Charlie Li <vishwin@freebsd.org>
Cc:        Gleb Popov <arrowd@freebsd.org>, Alan Somers <asomers@freebsd.org>,  FreeBSD Hackers <freebsd-hackers@freebsd.org>, Scott Long <scottl@freebsd.org>,  "Goran Meki??" <meka@tilda.center>
Subject:   Re: The Case for Rust (in the base system)
Message-ID:  <CANCZdfrEPqePpxbKgVnm%2BnyjtzGJPkvxyW5NssbQnmAOJJH6tQ@mail.gmail.com>
In-Reply-To: <eb4a9eb4-27ad-4be1-b1f4-49117d2ff6e0@freebsd.org>
References:  <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <CALH631=v4aWhFNDjZcnmjPnzFyZGhg%2BPuRmShx8TFvF6hPbnJQ@mail.gmail.com> <CANCZdfp67mMcDZkNHYLK=1CM=WTu_hn8=u9w3KwttZsZfEqPVw@mail.gmail.com> <eb4a9eb4-27ad-4be1-b1f4-49117d2ff6e0@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000054c36d060f683774
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jan 20, 2024 at 11:25=E2=80=AFAM Charlie Li <vishwin@freebsd.org> w=
rote:

> Warner Losh wrote:
> >
> >
> > On Sat, Jan 20, 2024, 10:14=E2=80=AFAM Gleb Popov wrote:
> >
> >     On Sat, Jan 20, 2024 at 7:51=E2=80=AFPM Alan Somers wrote:
> >      > To
> >      > summarize, the cost is that it would double our build times.
> >
> >     Would it? From what I remember, a lot of rust's build time comes fr=
om
> >     building its own LLVM. Can we reuse our base LLVM for Rust-in-base?
> >
> >
> > No. That's not possible in general.  Rust needs its own special thing
> > that is not well tested fit the non rust case.
> >
> Rust has followed vanilla LLVM since 8.0 and they have supported the
> external LLVM path since then. However, they use the shared library, LIT
> and a few other extras, all of which we don't build or include in base.
> They also have narrow LLVM version support windows, with only LLVM 15
> and later supported on Rust 1.74 and later. Further, release cycles are
> about every month, which maybe unless we stick strictly to Editions
> (language standards like C11, C++17, et al), sound like a problem for
> -RELEASEs.
>

Yea, Rust's fast velocity coupled with narrow compatibility bands would
be a bit of an impedance mismatch with the project. That's why I said it
isn't possible in general (one of many reasons, the one I cited actually
being obsolete it sounds). IT's the main reason why I'm suggesting that
if we want rust in the base, it should be done via an external toolchain
that
the rust advocates would maintain via a port (just like the folks that want
FreeBSD building via gcc have similar external toolchains).  That way,
there's
not per-se dependency in base on this and we'd get a feel for how that
works in practice as time passes and we have code on stable branches
that needs to continue to work (to pick one potential issue at random).
Until there's a way to reproducibly built programs, I maintain that it's
too early to talk about rust compiler in base.

Warner

--00000000000054c36d060f683774
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan 20, 2024 at 11:25=E2=80=
=AFAM Charlie Li &lt;<a href=3D"mailto:vishwin@freebsd.org">vishwin@freebsd=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">Warner Losh wrote:<br>
&gt; <br>
&gt; <br>
&gt; On Sat, Jan 20, 2024, 10:14=E2=80=AFAM Gleb Popov wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0On Sat, Jan 20, 2024 at 7:51=E2=80=AFPM Alan Somers=
 wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; To<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; summarize, the cost is that it would double o=
ur build times.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Would it? From what I remember, a lot of rust&#39;s=
 build time comes from<br>
&gt;=C2=A0 =C2=A0 =C2=A0building its own LLVM. Can we reuse our base LLVM f=
or Rust-in-base?<br>
&gt; <br>
&gt; <br>
&gt; No. That&#39;s not possible in general.=C2=A0 Rust needs its own speci=
al thing <br>
&gt; that is not well tested fit the non rust case.<br>
&gt; <br>
Rust has followed vanilla LLVM since 8.0 and they have supported the <br>
external LLVM path since then. However, they use the shared library, LIT <b=
r>
and a few other extras, all of which we don&#39;t build or include in base.=
 <br>
They also have narrow LLVM version support windows, with only LLVM 15 <br>
and later supported on Rust 1.74 and later. Further, release cycles are <br=
>
about every month, which maybe unless we stick strictly to Editions <br>
(language standards like C11, C++17, et al), sound like a problem for <br>
-RELEASEs.<br></blockquote><div><br></div><div>Yea, Rust&#39;s fast velocit=
y coupled with narrow compatibility bands would</div><div>be a bit of an im=
pedance mismatch with the project. That&#39;s why I said it</div><div>isn&#=
39;t possible in general (one of many reasons, the one I cited actually</di=
v><div>being obsolete it sounds). IT&#39;s the main reason why I&#39;m sugg=
esting that</div><div>if we want rust in the base, it should be done via an=
 external toolchain that</div><div>the rust advocates would maintain via a =
port (just like the folks that want</div><div>FreeBSD building via gcc have=
 similar external toolchains).=C2=A0 That way, there&#39;s</div><div>not pe=
r-se dependency in base on this and we&#39;d get a feel for how that</div><=
div>works in practice as time passes and we have code on stable branches</d=
iv><div>that needs to continue to work (to pick one potential issue at rand=
om).</div><div>Until there&#39;s a way to reproducibly built programs, I ma=
intain that it&#39;s</div><div>too early to talk about rust compiler in bas=
e.<br></div><div><br></div><div>Warner<br></div></div></div>

--00000000000054c36d060f683774--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrEPqePpxbKgVnm%2BnyjtzGJPkvxyW5NssbQnmAOJJH6tQ>