From nobody Tue Sep 10 15:11:54 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 4X36cX1ZS3z5W0PP for ; Tue, 10 Sep 2024 15:11:56 +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 4X36cW6q4gz4g42; Tue, 10 Sep 2024 15:11:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725981116; 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=Q8bvsp5fuAR2BhfKqkhSovNQ58jEVyS49XViHKvHa44=; b=D2LhrX9r5Hhqh+yIuK6+c1sLOrJ5cde60oCkSKREX4d64Jy3Qt/tNQlWFcNwHboWSGb56O L1/2cJk3XMDxqbAPfS8bjxbqZsp72vC5X/byXTCxqZLkvlG5udJtPgMqbH3yYNRxQYKOS/ atlIbDGzD/pErXc6/OrG3X3V5TPFt++bmAmf0cpT20Tx3wFR8TfMxgBAnaB02rC4bSnv6u EfmjI4OB2M9lRQVNhtJJ5j9SrDhoC1UIzovJziX/5KnHYRXdB5yYZm5sNL76yynXWeiSgd BggGM8fr1eEgQM4CkbitqTbGzgRVEh4/J5S+GhIho6bnQuHMmyDIU92UxpLgYQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725981116; a=rsa-sha256; cv=none; b=k2Wu6Z14Zh/ASyJlLCh6kwf/Zb5xfLBqkQNb2NlNlVw/i1RbU+CgGO8qOuTMR+f6DxWxf/ yzLy6+0UCivqEQR8AhoyMbiYQ9ZZoa1OwZYJbx1RtlNNSsz+WSMMFNBuEG9ByazOB3uHp4 ugf37Hup0Yiq15NCnWnjEhy2n8fZfurjxaQXHwmhx5EhAVFkIo/zIncsmjCj+OPCkx6DP/ HAukyKZ3tlKIsl3SpyQVk7awSUjFlv6R41tHNDFfFBC95uHEQDpCgPKcuOUdTMdTe8qjxh pU791w6Gr+INFgZim/AqIaBB1dU4809c6mOidqX3q5tonyUN81uhouugqvD57A== 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=1725981116; 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=Q8bvsp5fuAR2BhfKqkhSovNQ58jEVyS49XViHKvHa44=; b=wgKm+WmI6Siwq90dp4pNnjeZvH+PD4+vm1CXoF6Ln4QNp30hLjeiJBxGn5JJZ0CRFZ7nk1 RUcvtsytxp6STNl4ha2pb5GIloHRuQGwEiVc5acxvBTOGGE2B0kR4bJI1ywC6ygNsUqfbW 5uePEGkuqi27B7QaYXJXwo8Rcq5QFdUpECyoZYAxNBstFDFO4+72IFZfQfY/nV+i0LKNJP lCnP5IfIIjkZxCIZR7s7re/vLwdH/xW2JcO0FLIgDO9tsg/rxYXreQfS7m3AU30s45VEEC /iI9wcwukoZDRZfG+V1+3XKpMaIN7cVFf7cFjCvZncDocpdJ7La2cM2gFFMVuw== 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 4X36cW4ly1zTLR; Tue, 10 Sep 2024 15:11:55 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: Date: Tue, 10 Sep 2024 10:11:54 -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> Content-Language: en-US From: Kyle Evans In-Reply-To: <20240910234949.85d5a48c9b9f7bcf945794fc@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. > 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. > 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. 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. 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. Thanks, Kyle Evans