From nobody Wed Sep 4 08:03:13 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 4WzFNk3pJVz5TN8T for ; Wed, 04 Sep 2024 08:03:18 +0000 (UTC) (envelope-from rob@eatenbyagrue.org) Received: from fout1-smtp.messagingengine.com (fout1-smtp.messagingengine.com [103.168.172.144]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzFNj5klnz4L2X for ; Wed, 4 Sep 2024 08:03:17 +0000 (UTC) (envelope-from rob@eatenbyagrue.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=despairlabs.com header.s=fm2 header.b=bMPC8U9y; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=VmLXK9LV; dmarc=none; spf=pass (mx1.freebsd.org: domain of rob@eatenbyagrue.org designates 103.168.172.144 as permitted sender) smtp.mailfrom=rob@eatenbyagrue.org Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id 3DC0C1380263 for ; Wed, 4 Sep 2024 04:03:17 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Wed, 04 Sep 2024 04:03:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=despairlabs.com; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1725436997; x=1725523397; bh=v+KT2FR54d D5HP20HaIQyZ7xBu+1FxCb3mvhgPrSJIQ=; b=bMPC8U9ycdAbO5+gkrJmrgjE5u l4KL2TtaQel3pIg7tMXJwGAK7XoVQLcL1tFcjpHHInJRKgV+OTyNcQRVXmebRnJd 5SwC4nU+Rbp/zBGL2SHI9ujmIx3DKPp3vrAmt9EZnR7egjL2Vo3r6DyIdNiv3YIX 5iQslb7czo5PJ5u9Xe3ljANJPeQuio+0sVdzOEn+XGb9/c68oRW20/PuCL3wXya0 iwK04L3J2r0GazUd91QClGqz1fu9xlpHlIGUwVBn6xpBVN7agmzlxTNfObPDgHCP mnOiCFMyiLCkJMNKZjrhvRQ68JkQhjGXCIks2GltOojC1F4hjuPJsoJdNcRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1725436997; x=1725523397; bh=v+KT2FR54dD5HP20HaIQyZ7xBu+1 FxCb3mvhgPrSJIQ=; b=VmLXK9LVSaiyqZIiHGrIL6dwTM2gzWq2SrA2e1lobaAW ICNx1GJuQ+Lk8dpYEHG2LhVvAm6o13Vq1ygHIkA/GjOa/Ljtopv/AXPMCRXmcINZ hT+xe1yLujmBlMqOZ6KrNxKTp5PvKzqtnivtXCOPAJScyIxiaRvwPmHG3s+oaj5O W5D32BpZ3e7GqVJ2l3CbGcxMJ4nt/lor6iYu479F4BZzzXKGuWNpZrl7R58RbQvt bRE0aKfkers1GC2+F5v0pIMhiz9/H3b0WnwrKw7bmTAO92yjGaZTFulyfjNa1Z19 QeiEjLxA2QGhGOCZo7fJ65i6MddXtywPrAgHcSv59w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudehiedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvf fukfhfgggtuggjsehttdertddttdejnecuhfhrohhmpeftohgsucfpohhrrhhishcuoehr ohgsnhesuggvshhprghirhhlrggsshdrtghomheqnecuggftrfgrthhtvghrnhephfehud evfeeuudejieegiefggfejvdfhheefheehieeiuedvgfejtdduleffteeunecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhosgesvggrthgvnh gshigrghhruhgvrdhorhhgpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhu thdprhgtphhtthhopehfrhgvvggsshguqdhhrggtkhgvrhhssehfrhgvvggsshgurdhorh hg X-ME-Proxy: Feedback-ID: ia7b9477a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 4 Sep 2024 04:03:16 -0400 (EDT) Date: Wed, 4 Sep 2024 18:03:13 +1000 From: Rob Norris To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: References: <202409031131.483BVdax004602@critter.freebsd.dk> 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <202409031131.483BVdax004602@critter.freebsd.dk> X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[robn@despairlabs.com,rob@eatenbyagrue.org]; RWL_MAILSPIKE_VERYGOOD(-0.20)[103.168.172.144:from]; R_DKIM_ALLOW(-0.20)[despairlabs.com:s=fm2,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; RCVD_IN_DNSWL_LOW(-0.10)[103.168.172.144:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DMARC_NA(0.00)[despairlabs.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_NEQ_ENVFROM(0.00)[robn@despairlabs.com,rob@eatenbyagrue.org]; DKIM_TRACE(0.00)[despairlabs.com:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4WzFNj5klnz4L2X On 03.09.2024 11:31, Poul-Henning Kamp wrote: > But first and foremost: There has to be a good enough reason. This is a near-enough hook for me to hitch a couple of thoughts on to :) I work on ZFS, primarily on Linux with slowly increasing amounts on FreeBSD too. By a long way, the kind of work that is the slowest and most complicated is around complex locking sequences across multiple threads. In most of these, getting it wrong leads to some kind of data corruption that is usually impossible to track down. The appeal of Rust for me, as for many, is that there are ways to encode those kind of sequencing rules into the type system so that the compiler can tell you where you got it wrong. But, I don't actually want Rust _as such_. I like it a lot, I've written useful programs in Rust over the last decade, and I'd be perfectly happy to use it in kernel and filesystem development if it was available. What I actually want though is high-quality tools to make the kind of problems I need to solve easier for my puny human brain to manage. Rust is an approach to solving some of these kinds of problems. Other approaches exist, have existed, and will exist in the future. This is mostly aimed at the "C is totally fine" crowd. I like C, and I'm pretty good at it, but it absolutely not good enough for many kinds of software. Frankly, I find "just get better at C" to be the most infuratingly facile "argument" against Rust. (And I would _love_ to get better at C. If substantially better C tools are out there (on whatever axis you like to measure that on), then they're either not visible to me, or they're not usable or well-integrated enough to be in my standard kit). There's plenty of plausible reasons not to include Rust in the base system, many of them being discussed on this list, and I'm learning a lot reading along. Just please don't pretend the problems it's trying to solve aren't real. Cheers, Rob. -- Rob Norris | robn.au | robn@despairlabs.com Working on OpenZFS, because there's a lot of data out there and it'd be nice not to lose any of it.