From nobody Tue Jan 23 14:28:47 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 4TK8bf296Wz56w2Z for ; Tue, 23 Jan 2024 14:29:02 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TK8bd3hP8z4Nn4; Tue, 23 Jan 2024 14:29:01 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-f180.google.com with SMTP id 71dfb90a1353d-4bb6ee9fdb0so678868e0c.0; Tue, 23 Jan 2024 06:29:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706020140; x=1706624940; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c6oIq4u+YlQR7p4d8/U1VD3UzWp9VSdUV1P/eRuo9Y4=; b=p7SeKgIVvm7lI5uAnNORUbbeOSSDD1xlMTOpN9ZeAM0bz+MEtP5rbkbCjtnJBcaSP/ ahTXmiZlvr815dJj4R0Zk/8U2ec55zv55ngqz36X6pN5fuKKjE/QIjYMuceV1HVjb9/j 1ye7OsGBZs84pisnfVHab38367gpMN2MYoqdz8lxuAeDKFv0saV/XQYsB3iJDcPlHuRQ MNWQrl2Wgb1z9Ngw5/dEOv2LfV61EywTvtwNr3YrprEsALZ12oMhV1X9IaaHHqDC9FCi jYjxrNiuzyTiosKQ+KWXTLFFnT36H/HwYTjEPFb3nLmgnPBrsohSIDCKNNlvq9XqjYUJ ePUQ== X-Gm-Message-State: AOJu0YzRKV4hOHQS34R/X+pEBQpJoxxR2gEoq6e2jFySIhzzdpiVrFig /uRbMIhJEp2PDR7eWiwUIbvb9+hFAYU45QoiemJiEp0P1JfHJcLMbqDGs75c4trX/L7f9EGQnal /pozrR7WDhF8Y2Bt3sMQEriINrHAN8rEG X-Google-Smtp-Source: AGHT+IEEqM7HAGOkPIhvCnwMB61Wbf1gMyeJE/ngCviLvEOJI9pFZ3b3x2AGHICCXqi6hKzUTWbyH5eif9hag9Swb3g= X-Received: by 2002:a1f:4f42:0:b0:4b7:b55b:a8e9 with SMTP id d63-20020a1f4f42000000b004b7b55ba8e9mr2801980vkb.13.1706020139864; Tue, 23 Jan 2024 06:28:59 -0800 (PST) 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 References: <9b55eb431b63e1df4c66063bfcc5fe33@Leidinger.net> In-Reply-To: <9b55eb431b63e1df4c66063bfcc5fe33@Leidinger.net> From: Alan Somers Date: Tue, 23 Jan 2024 07:28:47 -0700 Message-ID: Subject: Re: The Case for Rust (in the base system) To: Alexander Leidinger Cc: FreeBSD Hackers , Warner Losh , Scott Long , meka@tilda.center Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TK8bd3hP8z4Nn4 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] On Tue, Jan 23, 2024 at 3:47=E2=80=AFAM Alexander Leidinger wrote: > > Am 2024-01-20 17:51, schrieb Alan Somers: > > In a recent thread on src-committers, we discussed the costs and > > benefits of including Rust code in the FreeBSD base system. To > > summarize, the cost is that it would double our build times. imp > > suggested adding an additional step after buildworld for stuff that > > requires an external toolchain. That would ease the build time pain. > > In case we allow more than C/C++ into the tree, but no matter if via > external or internal toolchain: Currently we are proud that we are able > to build rather old code on recent releases and we are even working on > this kind of backwards compatibility to some extend (e.g. building the > oldest supported release on the most recent in-development version). > > Which impact would any of the proposals have in this regard? > To my current understanding of the thread, an external toolchain may > result in losing this backwards compatibility even during the lifecycle > of a release (could I compile FreeBSD x.0 2 years later on x.y, or can I > compile x.y on x.0). This may be fixable (by having more than one rust > compiler in the ports tree, and sticking with a specific one for a given > release branch), but needs to be discussed / taken into account. Short answer: yes. Long answer: Rust has the concept of "editions", somewhat like C++ editions. A new edition comes out every 3 years. New editions are allowed to be backwards-incompatible, such as by adding new keywords, but crates must explicitly opt-in to the new edition. And a crate may depend on another crate that uses a different edition. Each compiler release is able to build the latest edition and all previous ones. So if we were to bring Rust code into the base system, we would probably want to settle on a single edition per stable branch. Then we would be able to compile it forever. The worst that could happen would be that newer compilers would introduce new warnings, which we might have to silence when building older code. > > As a generic voice of opinion: I agree with Warner Losh that providing > the possibility to play around and learn in a way which doesn't get into > the way of the functionality which we provide currently is a good first > step into getting hard factual data about possible benefits. I also > agree with David Chisnall that some "renovation" would be good in the > long term, and that current technologies provide ease of use not only in > security related but also in code quality and quality assurance related > areas compared to C. Not in terms of "we need to rewrite", but in terms > of "we need to provide the possibility to be able to make use of it". In > that regard it may be nice to set up some guidelines, e.g. if you use > C++, the target shall be C++17 / smart pointers / ... whatever (just to > use some words as examples which came up in this thread, not as a > suggestion that I want to have this written down as a rule), and if you > use Rust, you shall do X and Y, and if you use lua, do Z, if you use > python, ... So some kind of what we have for style but in terms of > coding guideline. Yes, exactly. I think that's what Robert Russell was getting at. How do you force people to use C++ smart pointers, for example, instead of dumb ones?