From owner-freebsd-hackers@freebsd.org Mon Dec 31 07:19:34 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 C8D461429542 for ; Mon, 31 Dec 2018 07:19:34 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) (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 53CF48D338 for ; Mon, 31 Dec 2018 07:19:34 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-pg1-f179.google.com with SMTP id t13so12431548pgr.11 for ; Sun, 30 Dec 2018 23:19:34 -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:from:date :message-id:subject:to:cc; bh=wBG4sqOlssAx4h3PrK+t/tXA+SE3C7ReEPn0db5fL9c=; b=rmWznROm8Pq5CYwmiuygDvoyT+NUUTmV+xiTrf91tXhdVpio8+j28MAd6/cUQHoYY4 DQnBKcLSQXw8RKaURSSv6XGJRzg/b6phgNsygfInoMLDe2lGdlMonJ7NOVZOdOpQiQ7H AikJOV857eHGINBlFZIrPXGT/tgYj7UAgZDI3i23BIGZlzzxcfe28DLArGoH9fEPceQ0 02K3oaijYy1PvqBBTt+ktY748K6sDTPnBv4Hy0Ovl6nm2qIW1m0vJOUZcl6hrfl7RsnI sWGykSs16ZzDmSIalv7qRrisJJLhnWSwD1wfkedGS4BKhOkDfgRxpqnhx41YSp8ZVZJG jyqQ== X-Gm-Message-State: AJcUukdgh0QjvSgfBOZnAFI4gWuMD5fbYqpQAYAwwz4aPA0GJKUeaO2v CZKYtaF4bT1QSBOAbcqyYW1fyntPv0Q= X-Google-Smtp-Source: ALg8bN7+CIj6gfUtl4r6LCj6lTI/6qid6hThoWdJ6JqEUZGVjGi1P3E2hBz5AEum6EUXEn/IXnMPdw== X-Received: by 2002:a65:4904:: with SMTP id p4mr6724379pgs.384.1546240320479; Sun, 30 Dec 2018 23:12:00 -0800 (PST) Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com. [209.85.215.179]) by smtp.gmail.com with ESMTPSA id p24sm75335202pfk.155.2018.12.30.23.11.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Dec 2018 23:11:59 -0800 (PST) Received: by mail-pg1-f179.google.com with SMTP id t13so12425592pgr.11 for ; Sun, 30 Dec 2018 23:11:59 -0800 (PST) X-Received: by 2002:a63:4a4d:: with SMTP id j13mr6757226pgl.127.1546240319719; Sun, 30 Dec 2018 23:11:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gleb Popov Date: Mon, 31 Dec 2018 10:11:09 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Speculative: Rust for base system components To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 53CF48D338 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_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 07:19:35 -0000 On Mon, Dec 31, 2018 at 8:38 AM Eric McCorkle wrote: > Before I begin, I want to be clear that everything here is in the realm > of speculative, long-term discussion. My goal is to start a > conversation, not to propose anything concrete right now. > > > > I've talked at several conferences about the possibility of bringing the > Rust programming language into the base system, with the intent of > making it a viable implementation language for parts of the base system. > I believe the potential security and stability benefits of doing this > are *substantial*. This would obviously be a serious undertaking, but I > think the benefits are worth the cost. For the rest of this mail, I'll > outline my position and present the important facts that support it. > > I of course welcome any discussion, criticism, or input. > > = Why Rust? = > > Rust is a true systems programming language that incorporates results > from programming language research that took place in the late 90's and > 2000's, and can be viewed as a culmination of this work. (Specifically, > it draws on work on region types as well as substructural types, but > that's its own survey article). > > This manifests most clearly in Rust's lifetime type system, which is > able to perform quite sophisticated reasoning about memory allocation > and ownership. Rust programs do not require you to explicitly manage > memory, but neither do they use garbage collection. Memory management > is automatically tracked by the lifetime types and allocations/frees are > added during compilation. Moreover, threaded programs are able to use > the same type system features to track ownership. This effectively > prevents a large class of memory- and concurrency-related errors *at the > type system level*, resulting in dramatically safer programs. Rust > provides an "unsafe" language facility for accomplishing low-level > tasks, so you're not prevented from getting things done; however, almost > all programs can be implemented without relying on unsafe, and doing so > eliminates what has probably been the two worst classes of bugs in the > history of computing. > If we are striving for safety through type system, I'd jump straight to Haskell. And let the bikeshedding begin. > Because this is done at the type system level, it has no cost at > runtime. This theme of "zero-cost abstractions" runs throughout the > language, which makes it suitable as a replacement for C in the long > term. It also incorporates features befitting a modern programming > language such as parameterized types (aka generics), pattern-matching, > and trait-based polymorphism. Finally, it can interface with C/C++ > binaries and libraries relatively easily, making it a suitable systems > implementation language. > > Because of these benefits, several projects (Mozilla and Tor) have begun > to reimplement their systems using Rust. Additionally, there is a > master's thesis about writing FreeBSD device drivers using Rust out > there somewhere (forgive me for not chasing it down). > > A secondary benefit is that Rust's packaging system, cargo, is built > around a more modern concept of modularity. This is in line with > FreeBSD's goals of modularizing the base system and reducing redundancy. > > = Downsides = > > There are a couple of downsides, which I'll outline briefly, and provide > some counterargumentation for them. > > * It's a big component > > Adding the entire Rust platform would add more to the buildworld time, > which is already quite long due to LLVM. OTOH, LLVM itself is a big > chunk of the rust build time, and we already build that as part of the > base system now. Moreover, it stands to reason that the compiler would > end up being the majority of an open-source operating system's build > time, with second place being the kernel itself. Compilers are an > active area of research with no signs of slowing down, and more hardware > platforms means more backends, which means the compiler ends up growing > over time, while most of the rest of the system doesn't. > > * The language is still evolving > > While this is true, the language has gotten *way* more mature in the > past year and a half, and I think it's ready to hold up major codebases > and production use, or at the very least it will be by the time we'd be > seriously looking at bringing it in. > > * Rust binaries are large > > This issue can be avoided with the proper use of build flags. The > default settings use static linking for everything, and bring in the > entire runtime library (which isn't necessary in most cases). See this > article: > https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html. > With LTO, the size can be cut down to that of a C++ binary, and with > dynamic linking, the executable size is comparable to a C program. If > we were seriously using rust, we would probably change the default flags > to use dynamic linking/LTO by default, in fact. > > > = Alternatives = > > There have been several alternatives that come up when I mention this. > I'll discuss the two big ones: go and C++ > > == C++ == > > C++ is already in the base system, of course. It could be brought into > the kernel with some effort and restrictions. The biggest argument for > Rust over C++ in my view is that Rust is a much simpler, cleaner > language. C++ at this point is bewilderingly complex as a language, and > has so many bells and whistles that it almost requires an effort to > decide which subset of the language will be used. This also tends to > slow down efforts to expand the language over time. > > Rust by comparison is much leaner. Its lifetime type system can be > intimidating, but the benefits are well worth getting used to it. To > sum it up, C++ certainly isn't going anywhere, but I think Rust has a > great deal more vitality as a language. > > == Go == > > Go is not really a "systems language" in the sense that C or Rust are. > It isn't a replacement for C so much as a replacement for python. > > What's more, it is almost universally disliked by people with a > background in programming languages (I am one of those). There's a > couple of reasons for this. First, it omits a number of features that > modern languages *really* should include, parameterized types (generics) > being one of the most glaring. Beyond that, it completely ignores > anything produced by modern PL research (unlike Rust, which benefits > from that work). Second, one of its main design parameters was "it > should compile fast". This as a design constraint basically guarantees > that you can't do anything interesting in compilation, which rules out > both advanced type systems as well as serious optimization. > > Unlike Rust, which offers substantial security and stability benefits > through its type system, Go would do little more than just change the > syntax of a bunch of code. Moreover, it's likely that there would be > performance consequences, given the design constraint of fast compilation. > > = Summary = > > Rust is a modern systems language with substantial benefits, and is > well-poised to become the heir apparent to C as the dominant systems > language going into the future. For this reason, I think we should > seriously consider it as a language for the base system at some point in > the future, when the time is right and after sufficient exploration and > experimentation. > >