From nobody Tue Sep 10 18:23:52 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X3Bt35G1Qz5WNP0 for ; Tue, 10 Sep 2024 18:23:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3Bt34MV8z4MHx; Tue, 10 Sep 2024 18:23:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725992635; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dBu/g2lta+TPSWR4rzmd90f/+0eXRA+rYdvfXDDk+1k=; b=SuIs9ED5gy9Gvq9jQmd70ZO373ENcK0K+TixGKZyUx5ZtYu5Qdh3FG8b1J7art42TbkGdl I0xlE8+ihFaeS4zSm6LRqfVjI6mvip4v3PM87IAxG6rHgMILh+cgWz1F87WufoKB9X2JvI CICgyrdbufIRPwIu1iTk/br258djdL7b/5aBLQ5sI4fv4gmok6GteR6F8hj7xwrj3XkWzM WGaXvfbNmTzFQNKNcvZ28W8+Pu5tjEvEEWdfDiNRa61RvQOyzNXTHYSV1om1KWhhwHvFMg kDFMqYhng6g8XxISw8LMPtLEwwXuf5hG4iK6nq9ERDf5aRYj9FbEYuWzutasCw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725992635; a=rsa-sha256; cv=none; b=Z6JaleW8FCPPmF83c6ZxUWHbRfBbxiJdDRZL75/hczCP/+bcXzqeaYO1vmPq9pNTHzGZ0X 7N5UdlQlQSSVSDEHHHadqs+P4vDWsoVjEbdEHGRepMfgTVDs5JJ/LhJ+PWtZPwFhO9Er2w uNZ8Q1M5FB5aliMVyHuNAmIV4PZUQKymw+h9pRhhbMdUVXmtxUTMdatIOr5cpjRepJsBgj TnZHnbjgOCaCljbRLM0U0oxQdq3j9s33adXd3fy8wngzNx0Pz/O9XYPOlVjH50xgJBR9TU x52vA4WuWSwtXqmekm8DewqAS2NOow+0ykih0Fr/G+0kdDN1GX8oJLkevMCqpQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725992635; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dBu/g2lta+TPSWR4rzmd90f/+0eXRA+rYdvfXDDk+1k=; b=C+4FH9coPEr2aZFvmPQ3rAOn2XIBOq73puQQpd3VesQZl2oePv8QkPGN4v2pQ8utmCxIS6 GaM+ywPSS/AdEpucBBanmmooWN3t/ldUFmPL8QhuhIQ/gauYEGvElD3SiQEREsx+qOuCjR zEenOE36c3y5/NqRaBYX1TcjE+sZHrNkh84SMgpfUsOxFxvoRUF1XIGnWjAtBhM1sNVDyU urUA8nj6E2BNfeoUKd49xR3N9fZocLyPGJCytziN1v+f1CyKexD0m6J0bmi+03UdoIBnzK Yc8D9fri3Vywi03ZrTSyf4TQx4YaZmJzo3eX4YN6f1/Bx3JUhvnjwpzweyUD6w== Received: from [10.9.4.95] (unknown [209.182.120.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X3Bt31pYWzY4G; Tue, 10 Sep 2024 18:23:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Tue, 10 Sep 2024 13:23:52 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in any system) To: Tomoaki AOKI Cc: freebsd-hackers@freebsd.org References: <49239d9a-aece-4b6b-b896-d7b4899149fc@FreeBSD.org> <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> <20240911010657.a23295639d222b057e883da2@dec.sakura.ne.jp> Content-Language: en-US From: Kyle Evans In-Reply-To: <20240911010657.a23295639d222b057e883da2@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/10/24 11:06, Tomoaki AOKI wrote: > On Tue, 10 Sep 2024 10:11:54 -0500 > Kyle Evans wrote: > >> On 9/10/24 09:49, Tomoaki AOKI wrote: >>> On Mon, 9 Sep 2024 16:11:40 -0500 >>> Kyle Evans 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 >> > >