From owner-freebsd-hackers@freebsd.org Mon Dec 31 21:29:40 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C35C141ACDD for ; Mon, 31 Dec 2018 21:29:40 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F4CA85F2F for ; Mon, 31 Dec 2018 21:29:39 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io1-f52.google.com with SMTP id m19so21989541ioh.3 for ; Mon, 31 Dec 2018 13:29:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=1Uccqb0ue4Lzlr4PALnUuOUiSKR8/93wBv+ljW/DmPA=; b=l+PLU1mS5gNtcS2eB4QPRmfDysTFbnOi+5cZQeQISpxk/+EDXa0TmGaJ09livLDb1k ItbD57NbqzdiZXH8Qu0JvNxhytIZIKD2+zojv3I9stpch4Qk/xrc7g86yu6wbPVFEHpf MWQuokxyQ14UPXpQqFg2T9dzbh6MJGgeEFSGG4QO9qioFGyMLoB73PR8gbc/AQpbACFS 1kXFOKWsW0RcWxxH6gBCC+r7X1O6yzW7DG0Te+J+UhF6ZiWJkJp8QfT6dzTbbKDreyle fLS0zWLCm6nQGqRACqNyKZrMVfs5V2jFX4UPn9H0WctJcmWRuGud1PuxxiIkuVibek5A zkrw== X-Gm-Message-State: AJcUukcDEii9EIChp3wMpjZHU9SWBXcqs0tv+/d64hIKRKsmXqQTHMhR 7hSr0qK7Wxpvbz40kZGl8SpsMjrq X-Google-Smtp-Source: ALg8bN5Nhy2Wh5phndXSsFR9h9ydA8iERpQiQEsnGnhnKPPi8Wto/GiZF0Yxq3LS9L5NEn05ESu+3g== X-Received: by 2002:a5d:8b06:: with SMTP id k6mr4063379ion.38.1546291274148; Mon, 31 Dec 2018 13:21:14 -0800 (PST) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com. [209.85.166.177]) by smtp.gmail.com with ESMTPSA id t6sm23428860ioc.87.2018.12.31.13.21.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Dec 2018 13:21:13 -0800 (PST) Received: by mail-it1-f177.google.com with SMTP id a6so34924841itl.4 for ; Mon, 31 Dec 2018 13:21:13 -0800 (PST) X-Received: by 2002:a24:b64a:: with SMTP id d10mr25105252itj.149.1546291273036; Mon, 31 Dec 2018 13:21:13 -0800 (PST) MIME-Version: 1.0 References: <414c837f-4b06-b6dc-468c-8bbbc8ad8c59@metricspace.net> In-Reply-To: <414c837f-4b06-b6dc-468c-8bbbc8ad8c59@metricspace.net> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Mon, 31 Dec 2018 13:21:02 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Speculative: Rust for base system components To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 7F4CA85F2F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.985,0]; TAGGED_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2018 21:29:40 -0000 Hi Eric, I don't disagree that C++ is worse than Rust in that regard. I just don't believe Rust is enough better to be a suitable *C* replacement (it's a perfectly fine C++ replacement). Things that are closer to suitable might be: 1. Enabling stronger C semantics and runtime enforcement over existing code. It might be possible to enable globally and selectively disable only on performance sensitive code, while still covering the majority of the system. Some work has been done by the Cambridge academics as part of CHERI / Cerberus / REMS ("Rigorous Engineering for Mainstream Systems"). A demo of Cerberus is online at http://cerberus.cl.cam.ac.uk/cerberus ; press 'forward' a few times. Or it could be something else (UBSan and ASan on security-critical userspace programs?). But the migration path from existing code is more clear and requires less "throw away the world" as step 1. 2. Ziglang seems somewhat promising. It's still immature and I am certainly not claiming the pros of rewriting components or including new compilers in base outweigh the cons. But its aims are closer to C than C++ or Rust (simplicity, no operator overloading) and that seems a better fit. It is also based on LLVM, which comes with some of the same drawbacks as Rust (or Clang, for that matter) re: toolchain build time and supported architectures. https://github.com/ziglang/zig Best, Conrad On Mon, Dec 31, 2018 at 9:59 AM Eric McCorkle wrote: > > On 12/31/18 1:56 AM, Conrad Meyer wrote: > > Rust has many of the exact same problems C++ has. Sure, it avoids a > > few classes of issue. But it doesn't fix the classic C++ problems of > > extremely slow build times (if you think C++ is bad, Rust is worse) > > and having a kitchen sink of language features that make Rust and C++ > > code difficult to grok. > > I would debate the kitchen sink claim. For one, Rust benefits from a > solid understanding of type systems that didn't exist when C++ was > created. Proper parameterized types are a significant improvement over > C++ templates (the same holds for Java's generics, but that's > tangential). This alone reduces the complexity of the language (and its > error messages) considerably. While I give C++ slack on the issue of > templates because Somebody Had To Go First, that doesn't mean I relish > the idea of writing C++ code. > > Beyond that, the C++ standardization process these days is seemingly > aiming at bringing everything under the sun into the language itself, > whereas Rust went for a syntax extension system and an overall language > design that avoids the need to graft everything into the language > itself. (Side note: as much as I loathe macros in programming > languages, Rust actually seems to have produced a reasonable macro-like > system) >