Date: Tue, 10 Sep 2024 13:23:52 -0500 From: Kyle Evans <kevans@FreeBSD.org> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <a3cfa6fd-e29d-4c43-bc5e-7209630ed27d@FreeBSD.org> In-Reply-To: <20240911010657.a23295639d222b057e883da2@dec.sakura.ne.jp> References: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com> <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> <c8b52bcd-725d-473e-a30c-a611b9c2e44c@FreeBSD.org> <20240911010657.a23295639d222b057e883da2@dec.sakura.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/10/24 11:06, Tomoaki AOKI wrote: > On Tue, 10 Sep 2024 10:11:54 -0500 > Kyle Evans <kevans@FreeBSD.org> wrote: > >> On 9/10/24 09:49, Tomoaki AOKI wrote: >>> On Mon, 9 Sep 2024 16:11:40 -0500 >>> Kyle Evans <kevans@FreeBSD.org> wrote: >>> >>>> On 9/5/24 13:09, Alan Somers wrote: >>>>> By now I expect that most of you have seen the long list of new >>>>> security advisories that just came out. Strikingly, all were the >>>>> result of memory handling errors. And none of them wouldn't have >>>>> happened if their respective programs had been written in a >>>>> memory-safe language. >>>>> >>>>> In fact, of all the C bug fixes that I've been involved with (as >>>>> either author or reviewer) since May, about three quarters could've >>>>> been avoided just by using a better language. >>>>> >>>>> The real takeaway here is that C is no longer sufficient for writing >>>>> high quality code in the 2020s. Everyone needs to adapt their tools. >>>>> Programmers who don't will increasingly come to resemble experimental >>>>> archaeologists, i.e. people who learn flintknapping to "keep the >>>>> knowledge alive". Such people are valuable, but definitely niche. I >>>>> for one don't want my career to go in that trajectory. >>>>> >>>>> To summarize, here's the list of this week's security advisories, and >>>>> also some other recent C bug fixes of my own involvement: >>>> > [... snip ...] >>>> >>>> If even half of the energy that has gone into these threads would've >>>> been spent on a proof-of-concept rust-xtoolchain implementation with >>>> some motivating cases instead, we'd be in a lot better place to actually >>>> have these conversations. >>>> >>>> Thanks, >>>> >>>> Kyle Evans >>> >>> Shawn would be working on the PoC now. Let's see how it goes. >>> >>> The worst is that the work is rejected AFTER it's almost done. >>> It's clearly wastes of times/efforts. >>> >> >> IMO if (general) you did enough work that you're angry about it being >> rejected, then you probably did way more than you should've for the >> stage we're at. If you're rewriting major utilities/daemons for a PoC / >> talking point, then you're doing it wrong. > > Angry or not does not at all matter here. > Proceeding wrong direction because of insufficient discussion and > consensus is the waste of time. > > Introducing brand-new language(s) into base is quite a large movement. > So my guess is that now is still the time for "brainstorming" before > starting actual and effective discussions. > It's really not a large movement, though, to get the bare basics done to evaluate a new language. As stated repeatedly, we don't need the toolchain for a new language in base and the new language wouldn't be in the 'default on' path. That's not exactly a huge commitment, then you talk about where it needs to go from there (preferably as part of pre-commit discussion, but also ongoing as you want to try and expand). > >>> My guess about this thread is that it is needed to determine what is >>> acceptable, what's not, what's needed to be confirmed. >>> >> >> Except it's been increasingly clear even before this discussion fired up >> again that a large chunk of the people involved don't have a good point >> of reference to even have this discussion. You're wearing them down on >> the topic before you even have something to point at and say "Hey, this >> is what it might look like" and maybe a roadmap for some of the >> low-hanging fruit for things we can improve with it. > > Again, I think now is still at the time (phase/state) of brainstorming. > Non-chaotic brainstorming is in many cases useless. > We'll have to agree to disagree on that, I don't really see much productive vs. slightly different phrasings of the same arguments. > >>> Clarifying the above as much as possible before starting the work is >>> a good thing. Now we know how many pros&cons exists, and what are >>> proposed as possible alternatives. Unfortunately, it's still "chaotic" >>> and maybe need some more times. >>> >>> And discussions are ongoing at forums.frebsd.org, too. [1] >>> It already is quite a long thread. >>> >>> >>> [1] >>> https://forums.freebsd.org/threads/the-case-for-rust-in-the-base-system.92024/ >>> >> >> I'd go as far as to say that none of this is all that useful until we >> can evaluate how much pain we're in for in trying to add this >> dependency, but we're apparently more interested in discussing it to >> death without putting in the effort to demonstrate the feasibility >> through bare minimum integration. > > What's making it difficult is that Rust is still a "moving goal". > No standards yet. So we have some more time until it settles. > That doesn't stop anyone from doing the basic xtoolchain integration. > >> It's not very encouraging for future work in the area between that and >> also that the request made months ago for something tangible to point at >> to discuss further was answered by exactly one person who's already >> terribly busy. It's great that he's trying to make time, but you >> would've thought from these threads that *someone*, *anyone* would have >> made time with all of this demonstrated passion if they really cared >> enough to push it forward. > > Unfortunately, right, maybe. > But the direction Shawn noted for his PoC seems becoming better than > the start of these brainstorming. > > >> We've been able to use C++ in base in a safer fashion for years and that >> simply has not happened, so one has to question the interest in >> alternatives. > > Yes, C++ is already in our base toolchain. > But unfortunately, C++ doesn't seem to be treated as memory-safe > language. [2] So switching to C++ can cause future (governmental) > pressures for rewriting with another language again. > > [2] > https://www.techrepublic.com/article/white-house-report-memory-safe-programming-languages/ > > Regards. > >> >> Thanks, >> >> Kyle Evans >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a3cfa6fd-e29d-4c43-bc5e-7209630ed27d>