Date: Tue, 3 Sep 2024 12:10:33 -0600 From: Warner Losh <imp@bsdimp.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-hackers@freebsd.org Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Message-ID: <CANCZdfrhK1iTZL5uxciqK_FGb%2Bzha_NZ15LsY42f%2B_z3KbPmJw@mail.gmail.com> In-Reply-To: <202409031532.483FW0If007252@critter.freebsd.dk> References: <202409031532.483FW0If007252@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000e36bc606213af9c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 3, 2024 at 9:32=E2=80=AFAM Poul-Henning Kamp <phk@phk.freebsd.d= k> wrote: > As part of the migration, we yank LLVM out of the src. > > "pkg upgrade" also upgrade kernel and userland packages - Welcome to > the century of the fruitbat. > > And yes, we have ports written in Rust, why do you ask? > pkgbase is the path forward. It is the future. We are better off putting all our horses behind that effort so we can make it the default install in 15.0. Once we have that, this whole debate becomes moot, for the most part. Userland in rust can compete with userland in C. And with go, python, etc for whatever does the job the best. If rust is so much better, then people will use it, otherwise they will use the C version. It doesn't become moot for the kernel, but the kernel is much harder. The crux of the issue is that adding Rust bindings double our work to improve and evolve the system: it has to be done for C and for Rust and we have to make sure work done in one doesn't break the other. When you strip off the drama from the Linux dust-up over this, that's one of the fundamental issues that the Linux kernel developers are trying to get answers to and failing. Warner --000000000000e36bc606213af9c5 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 Tue, Sep 3, 2024 at 9:32=E2=80=AFA= M Poul-Henning Kamp <<a href=3D"mailto:phk@phk.freebsd.dk">phk@phk.freeb= sd.dk</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:= 1ex">As part of the migration, we yank LLVM out of the src.<br></blockquote= ><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px= 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"p= kg upgrade" also upgrade kernel and userland packages - Welcome to<br> the century of the fruitbat.<br></blockquote><div>=C2=A0</div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli= d rgb(204,204,204);padding-left:1ex"> And yes, we have ports written in Rust, why do you ask?<br></blockquote><di= v><br></div><div>pkgbase is the path forward. It is the future. We are bett= er off putting all our</div><div>horses=C2=A0behind that effort so we can m= ake it the default install in 15.0.</div><div><br></div><div>Once we have t= hat, this whole debate becomes moot, for the most part.</div><div>Userland = in rust can compete with userland in C. And with go, python, etc</div><div>= for whatever does the job the best. If rust is so much better, then people<= /div><div>will use it, otherwise they will use the C version.</div><div><br= ></div><div>It doesn't become moot for the kernel, but the kernel is mu= ch=C2=A0harder. The crux of the issue</div><div>is that adding Rust binding= s double our work to improve and evolve the system: it has</div><div>to be = done for C and for Rust and we have to make sure work done in one doesn'= ;t break</div><div>the other. When you strip off the drama from the Linux d= ust-up over this, that's one of</div><div>the fundamental issues that t= he Linux kernel developers are trying to get answers to and</div><div>faili= ng.</div><div><br></div><div>Warner</div></div></div> --000000000000e36bc606213af9c5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrhK1iTZL5uxciqK_FGb%2Bzha_NZ15LsY42f%2B_z3KbPmJw>