From nobody Tue Jan 23 17:15:10 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 4TKDHS1fBVz57k2d for ; Tue, 23 Jan 2024 17:15:16 +0000 (UTC) (envelope-from robert@rrbrussell.com) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (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 4TKDHR4Nmwz41Vr for ; Tue, 23 Jan 2024 17:15:15 +0000 (UTC) (envelope-from robert@rrbrussell.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rrbrussell.com header.s=fm2 header.b="BC/iR+zz"; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="B b0mz+v"; dmarc=pass (policy=quarantine) header.from=rrbrussell.com; spf=pass (mx1.freebsd.org: domain of robert@rrbrussell.com designates 64.147.123.19 as permitted sender) smtp.mailfrom=robert@rrbrussell.com Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 705E33200A20 for ; Tue, 23 Jan 2024 12:15:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 23 Jan 2024 12:15:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rrbrussell.com; h=cc:content-transfer-encoding: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=1706030112; x=1706116512; bh=Lrkx0J5ckjD298GBF9n8o/YJkQgkWBAdW6ZMZty51uo=; b= BC/iR+zznHI71SPaexwweFAj9aTtu4JUzqNi1yFVtl9WtquMPC21sXeB1bsfBz1w fohl5/QYs05ndaMahf7H2dGGXVSCmQQ78RY+rvdojSmja9mf3Gd22wOx2dYOCVpk eFf1bi6SZdhLYLCe6MtQ85xvchma+b69sfqyFAPrlyKzG/bNG3EowCDp8gzv1dCW pdwfEzzr2AVEWQPtcfP78GaOTLvxdMusFs4DT48mqsWSuU7P5tCHLx5fYz7hFNeJ MNK63lE+rA0MKF9+G4RdBIfNPyYqjToKrezYdG+qP6CDfB7uBvk2mYIhwqQ6U1tc bcqsw2wXu0muGD25k3Rjtg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; t=1706030112; x= 1706116512; bh=Lrkx0J5ckjD298GBF9n8o/YJkQgkWBAdW6ZMZty51uo=; b=B b0mz+v/fiwSqZOquCQlD5pAu6H6/p9ZZtJcBMJnXdVOLj4YxhHAMhmVjdf42WcA4 +fRCto7x/czY4ozVLpLYuvNUzS/XTLZofDLCLEC6aqc/R5YbgSWJm0lMHmQ7A9ch VpuF77Z9uofRUY2HLn19CDm5X4+dHZOcDjxkvpBy2ane1RtFodrw2CEOV8nZwiYi 3ktQFG2JJEmcHeFcRVsJ1KgGaxzqFvyVl8wl8FsSJRyqqM0UAC2K+pVWeQw4HxQ6 qhzmCxQm1OjVF6wNTBrO9kMi7UdH80jcpdoW0N0okgQg7mVYyJswwZG9h2odF/m2 sMZ67TPMVHXlbrgk30VyA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdekkedgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtqh ertdertdejnecuhfhrohhmpedftfhosggvrhhtucftrdcutfhushhsvghllhdfuceorhho sggvrhhtsehrrhgsrhhushhsvghllhdrtghomheqnecuggftrfgrthhtvghrnhephfehfe ffieeihfdutdeugfffjeeiffeuhedtgfejfeeugeegheekgfdvvedtffeknecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhosggvrhhtsehrrh gsrhhushhsvghllhdrtghomh X-ME-Proxy: Feedback-ID: ie421460a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 23 Jan 2024 12:15:12 -0500 (EST) Date: Tue, 23 Jan 2024 11:15:10 -0600 From: "Robert R. Russell" To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: <20240123111510.23aa4e18@venus.private.rrbrussell.com> In-Reply-To: <48FF6847-FCF0-4B6D-AC67-E3B939294847@FreeBSD.org> References: <1673801705774097@mail.yandex.ru> <202401210751.40L7pWEF011188@critter.freebsd.dk> <20240121102421.GE14773@memo2.memo.frmug.org> <2f38cbcd-61a9-42b7-b7e6-ebd261fe66da@FreeBSD.org> <20240122164543.066e3cec@venus.private.rrbrussell.com> <20240123085540.42f8b70c@venus.private.rrbrussell.com> <48FF6847-FCF0-4B6D-AC67-E3B939294847@FreeBSD.org> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[rrbrussell.com,quarantine]; RWL_MAILSPIKE_EXCELLENT(-0.40)[64.147.123.19:from]; R_DKIM_ALLOW(-0.20)[rrbrussell.com:s=fm2,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.19]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[rrbrussell.com:+,messagingengine.com:+]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[robert]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[messagingengine.com:dkim] X-Rspamd-Queue-Id: 4TKDHR4Nmwz41Vr On Tue, 23 Jan 2024 15:04:31 +0000 David Chisnall wrote: > On 23 Jan 2024, at 14:55, Robert R. Russell > wrote: > >=20 > > The specific anti-patterns is was thinking of in both instances is > > called Meta Template Programming. Back in C++03 I just used the > > template system as a form of generics. In that role it works well > > and with the new smart pointers definitely improves some of the > > older problems C++ had. =20 >=20 > Template metaprogramming is a core feature of C++, and more recent > versions have added constexpr / consteval / constinit and concepts to > make it a lot more readable. It can be abused, but it is not, in > itself, bad. My example from earlier in the thread used template > metaprogramming to do compile-time checks of correctness of the > overflow / wrapping behaviour of a ring buffer. Making it easy to > check properties of your code at compile time is very much a feature, > not an antipattern and it=E2=80=99s hard to see how you could argue the > converse without arguing that bugs are a good idea. > >=20 > > However, C++ definitely has a complexity cult and a ricer cult in > > its community. The overlap between the two appears to be fairly > > large which worries me. =20 >=20 > Non-specific ad-hominem arguments are tremendously unhelpful. It sounds like I could read the code you talked about and grasp what the intention was even if I didn't understand exactly how you were achieving the task. The groups I was commenting about have a preference for people not being able to do that. The "Ricers" use speed as their justification. > > I have less reservations about C++ than I did earlier, though I > > think the build system may require major surgery to support it > > well. =20 >=20 > The build system for both userspace and the kernel already support > C++. I have written a kernel module in C++ in the past. Currently, > there=E2=80=99s no mechanism in the kernel loader to support COMDATs (and= I > don=E2=80=99t really want to add it, I=E2=80=99d much rather handle them = as an > install-time preprocessing step for kernel modules), so you can=E2=80=99t > load kernel modules that use inline functions / variables, but that=E2=80= =99s > orthogonal to the build system. >=20 > David >=20 I was mainly thinking about handing things like setting the proper variables so the LSP servers work or being able to do some static analysis before commits.