Date: Tue, 23 Jan 2024 07:28:47 -0700 From: Alan Somers <asomers@freebsd.org> To: Alexander Leidinger <Alexander@leidinger.net> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Warner Losh <imp@bsdimp.com>, Scott Long <scottl@freebsd.org>, meka@tilda.center Subject: Re: The Case for Rust (in the base system) Message-ID: <CAOtMX2jdw7yNGhWKUU9Cu%2BgmBWd7=g5ngAC89dJftwLLHfFTjw@mail.gmail.com> In-Reply-To: <9b55eb431b63e1df4c66063bfcc5fe33@Leidinger.net> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <9b55eb431b63e1df4c66063bfcc5fe33@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 23, 2024 at 3:47=E2=80=AFAM Alexander Leidinger <Alexander@leidinger.net> wrote: > > Am 2024-01-20 17:51, schrieb Alan Somers: > > In a recent thread on src-committers, we discussed the costs and > > benefits of including Rust code in the FreeBSD base system. To > > summarize, the cost is that it would double our build times. imp > > suggested adding an additional step after buildworld for stuff that > > requires an external toolchain. That would ease the build time pain. > > In case we allow more than C/C++ into the tree, but no matter if via > external or internal toolchain: Currently we are proud that we are able > to build rather old code on recent releases and we are even working on > this kind of backwards compatibility to some extend (e.g. building the > oldest supported release on the most recent in-development version). > > Which impact would any of the proposals have in this regard? > To my current understanding of the thread, an external toolchain may > result in losing this backwards compatibility even during the lifecycle > of a release (could I compile FreeBSD x.0 2 years later on x.y, or can I > compile x.y on x.0). This may be fixable (by having more than one rust > compiler in the ports tree, and sticking with a specific one for a given > release branch), but needs to be discussed / taken into account. Short answer: yes. Long answer: Rust has the concept of "editions", somewhat like C++ editions. A new edition comes out every 3 years. New editions are allowed to be backwards-incompatible, such as by adding new keywords, but crates must explicitly opt-in to the new edition. And a crate may depend on another crate that uses a different edition. Each compiler release is able to build the latest edition and all previous ones. So if we were to bring Rust code into the base system, we would probably want to settle on a single edition per stable branch. Then we would be able to compile it forever. The worst that could happen would be that newer compilers would introduce new warnings, which we might have to silence when building older code. > > As a generic voice of opinion: I agree with Warner Losh that providing > the possibility to play around and learn in a way which doesn't get into > the way of the functionality which we provide currently is a good first > step into getting hard factual data about possible benefits. I also > agree with David Chisnall that some "renovation" would be good in the > long term, and that current technologies provide ease of use not only in > security related but also in code quality and quality assurance related > areas compared to C. Not in terms of "we need to rewrite", but in terms > of "we need to provide the possibility to be able to make use of it". In > that regard it may be nice to set up some guidelines, e.g. if you use > C++, the target shall be C++17 / smart pointers / ... whatever (just to > use some words as examples which came up in this thread, not as a > suggestion that I want to have this written down as a rule), and if you > use Rust, you shall do X and Y, and if you use lua, do Z, if you use > python, ... So some kind of what we have for style but in terms of > coding guideline. Yes, exactly. I think that's what Robert Russell was getting at. How do you force people to use C++ smart pointers, for example, instead of dumb ones?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jdw7yNGhWKUU9Cu%2BgmBWd7=g5ngAC89dJftwLLHfFTjw>