Date: Thu, 25 Jan 2024 10:22:58 -0800 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: <CAJ-VmokX3_GNQdFY9vkS0XMJHAWbTMFU0gyFuF60oEqXdVUHLg@mail.gmail.com> In-Reply-To: <ZbJ8S6nqiw9_Grzs@int21h> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <ZbJ8S6nqiw9_Grzs@int21h>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000a6375d060fc945e8 Content-Type: text/plain; charset="UTF-8" On Thu, 25 Jan 2024 at 07:20, void <void@f-m.fm> wrote: > Hi, > > Somewhat adjacent to this discussion - what I'd like [1] to see, as a user > rather than a developer, is a system-stable rust, so that if/when > something needs rust, it uses the system-specific version. > > Let's say when there's a new freebsd version. This has, say, rust v1.72. > It's not src-rust in that rust wouldn't be used to build freebsd source. > But the binaries would be there, selectable on freebsd installation, > much as one can select kern-dbg from the installer. > > Then in ports, one of the options might be 'use system rust' [X] > so avoiding the churn that happens constantly. > The challenge isn't necessarily rust though. As said before, it's the ecosystem of library code developers use to build software. I've been playing with rust a bit for resource constrained embedded systems code, and there's only so much you can do before you have to import something and then ... dependencies can blossom if you're not super careful. You also don't want to be stuck where the system version of rust can't compile the updated crates. The supply chain issue is also super valid. A lot of stuff just "assumes" they can download stuff from the internet during build, and for companies that wish to avoid said supply chain issues, they'll end up starting to build their own repositories of crates. And we'd have to do the same, since rust and its own set of base libraries only gets you so far. Then you hope (!) that you don't have crate versions that are different for each piece of software you're importing. (And I'm pretty sure any rust developers will riot if you try to say something like "rust in base for base tools, but no crates or only these subset of crates that we check into vendor/. They'll end up wanting ... more. :-) (To echo phk, I kinda feel like this is a perennial issue of languages being in that fun triangle that poor devops folks have to be responsible for when integrating into something more .. formal. :-) -adrian --000000000000a6375d060fc945e8 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 Thu, 25 Jan 2024 at 07:20, void &l= t;<a href=3D"mailto:void@f-m.fm">void@f-m.fm</a>> wrote:<br></div><block= quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1= px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> Somewhat adjacent to this discussion - what I'd like [1] to see, as a u= ser<br> rather than a developer, is a system-stable rust, so that if/when<br> something needs rust, it uses the system-specific version.<br> <br> Let's say when there's a new freebsd version. This has, say, rust v= 1.72.<br> It's not src-rust in that rust wouldn't be used to build freebsd so= urce.<br> But the binaries would be there, selectable on freebsd installation,<br> much as one can select kern-dbg from the installer.<br> <br> Then in ports, one of the options might be 'use system rust' [X]<br= > so avoiding the churn that happens constantly.<br></blockquote><div><br></d= iv><div>The challenge isn't necessarily rust though. As said before, it= 's the ecosystem of library code</div><div>developers use to build soft= ware. I've been playing with rust a bit for resource constrained</div><= div>embedded systems code, and there's only so much you can do before y= ou have to import</div><div>something and then ... dependencies can blossom= if you're not super careful.</div><div><br></div><div>You also don'= ;t want to be stuck where the system version of rust can't compile the = updated crates.</div><div><br></div><div>The supply chain issue is also sup= er valid. A lot of stuff just "assumes" they can download stuff</= div><div>from the internet during build, and for companies that wish to avo= id said supply chain issues,</div><div>they'll end up starting to build= their own repositories of crates. And we'd have to do the same,</div><= div>since rust and its own set of base libraries only gets you so far. Then= you hope (!) that you don't</div><div>have crate versions that are dif= ferent for each piece of software you're importing.</div><div><br></div= ><div>(And I'm pretty sure any rust developers will riot if you try to = say something like "rust in base</div><div>for base tools, but no crat= es or only these subset of crates that we check into vendor/. They'll</= div><div>end up wanting ... more. :-)</div><div><br></div><div>(To echo phk= , I kinda feel like this is a perennial issue of languages being in that fu= n triangle</div><div>that poor devops folks have to be responsible for when= integrating into something more .. formal. :-)</div><div><br></div><div><b= r></div><div>-adrian</div><div><br></div><div>=C2=A0</div></div></div> --000000000000a6375d060fc945e8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokX3_GNQdFY9vkS0XMJHAWbTMFU0gyFuF60oEqXdVUHLg>