From nobody Wed Sep 11 23:13:44 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 4X3xGF0qFHz5WHMP for ; Wed, 11 Sep 2024 23:13:57 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3xGD6Gltz45rj for ; Wed, 11 Sep 2024 23:13:56 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f47.google.com with SMTP id ada2fe7eead31-49bc672bb46so144477137.2 for ; Wed, 11 Sep 2024 16:13:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726096436; x=1726701236; 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=6GtGqPGax+vMplbKTN+HdWckoxjHFlMpGdluodONGGk=; b=T+LEjlkLolKqeC0cZrAOXVeHqfzUi0jhbj1HQ0hN1z+EK3ADUUyIP1pHPm7vwh3t4e mSYUkRi8eEdfbVD6+noVrzxPJvD0mKTH9flzI0S9IHlNrDlJ20IWdxtjOcJbxEM3gRSj m7iD3gzAHPr+gak14r6Fse3gvupbRLZktstNlYFg3i9flTWHJafmW0WX1YcMVKpmcB85 pRxRTZrTqluRKvlZ3ZRZKnJucfxBWiNI9pLvEEviN9HUN9anFcoLMqtbL1oTKu7pGBvr tZoJY1xLCitrrWYKRjN1Id/JX8WqI8Hx4f3lyZ2nNTQxgX/+nT3zi0sWbqrgqPWYelqG e1RQ== X-Forwarded-Encrypted: i=1; AJvYcCXIuMFnJJUQSsFrRgqL+R2YVakQyucZTyyyryASKZwvmAGkdQ3mw7bmLd1kdqNc64DtNqsvyTbOkwdFabWKTZA=@freebsd.org X-Gm-Message-State: AOJu0YxxHq5fAuEaSYMtBardNvrQv6pKqs7Bo7ZEsXMQycxrlW4jTAXr GBOkJ38OBjLPZimJDG72RsbhcRBB6z//3KYRvTwX4Oix2rOZ4F4j/5mG+xL2IazCYQ0l/pJStjM 6sk8/CqMxPC0H5ptb4d7CDAcLYPN91A== X-Google-Smtp-Source: AGHT+IEhJ4adGR/ob7jgPhVH4oCQfiUaYuQmhQjvnIW40oSXEoFWAzq//KCbVBQFy1IAhK0qjYuRtSIgn6jTE1ZCFd0= X-Received: by 2002:a05:6102:4424:b0:49a:1ccd:35c7 with SMTP id ada2fe7eead31-49d4155e8dfmr1303891137.19.1726096435771; Wed, 11 Sep 2024 16:13:55 -0700 (PDT) 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: In-Reply-To: From: Alan Somers Date: Wed, 11 Sep 2024 17:13:44 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Chris Cc: Warner Losh , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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] X-Rspamd-Queue-Id: 4X3xGD6Gltz45rj On Wed, Sep 11, 2024 at 4:41=E2=80=AFPM Chris wrot= e: > > On 2024-09-05 13:36, Alan Somers wrote: > > On Thu, Sep 5, 2024 at 2:16=E2=80=AFPM Warner Losh wro= te: > >> > >> > >> > >> On Thu, Sep 5, 2024 at 12:10=E2=80=AFPM 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. > >> > >> > >> FreeBSD represents hundreds of thousands or millions of man hours > >> in its current form (depending on how you measure it). It has evolved > >> over 30 years. To get to the same level of maturity in a rust rewrite = would > >> take a similar amount of time. But even if it took an order of magnitu= de > >> less because rust is that much better, that represents a huge pool of > >> manpower that don't seem to be hanging out around the project just > >> waiting for something to do. > > > > Sure. I for one am not volunteering to rewrite CTL next week. > > > >> > >> Where do the resources for this come from? Without enough resources, > >> the rewrites will be crap and nobody will want to use them (or maybe e= ven > >> FreeBSD). The rewrites to date have lost functionality (though maybe n= ot > >> functionality that's important) relative to what they replace. > > > > Which rewrites are you thinking of? > > > >> > >> So great, we should switch to rust. But so far we have no way to do th= at > >> incrementally (other than a parallel build system, which isn't very > >> FreeBSDish). > >> And if we can't even find the resources to do that minimal level of wo= rk, > >> how > >> can the rest possibly be robustly undertaken? > >> > >> Warner > > > > Your point is obvious; FreeBSD is too big to rewrite the whole thing. > > But my point stands: new projects (whether inside of FreeBSD or not) > > should almost always be using a safe language. And any component that > > needs a major overhaul anyway should probably also be written in a > > safe language, too. > I don't think the problem is the language. C has proven to be an extremel= y > powerful and capable language. If it were made impotent enough to prevent > people from making mistakes. Would it be potent enough to do what needs t= o be > done? > IOW the people that use it are the problem. Not the language. Is *any* > language > that prevents one from shooting themselves in the foot powerful enough to= be > of any value? I say not. It will always be a matter of quality control, a= nd > until humans are made to be infallible. This will thread will continue. > I know, I know, it's all philosophical, but still... "Memory safety =3D=3D restrictive training wheels" is just a common misconception. I've personally written 100k SLOC in Rust and I've very rarely found anything that the compiler "won't let me do". (TBH It does very rarely happen, because of certain patterns that the borrow checker doesn't understand, but the extra effort I've had to spend to overcome those cases is dwarfed by the effort that I would've expended to solve the same problems in C). And if you *really* need to break the rules, there's always the `unsafe` keyword. If you've never used a more modern systems programming language than C, then I encourage you to try one out for a few months. You won't regret it. -Alan