From owner-freebsd-hackers@freebsd.org Tue Jan 1 03:04:13 2019 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 3F0F2142533F for ; Tue, 1 Jan 2019 03:04:13 +0000 (UTC) (envelope-from brian@aceshardware.com) Received: from mail.aceshardware.com (mail.aceshardware.com [52.52.37.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 055E26A262 for ; Tue, 1 Jan 2019 03:04:11 +0000 (UTC) (envelope-from brian@aceshardware.com) Received: from [10.0.0.102] (unknown [71.145.208.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.aceshardware.com (Postfix) with ESMTPSA id EF12420130F for ; Tue, 1 Jan 2019 03:04:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aceshardware.com; s=dkim; t=1546311843; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UHsLWKt9ThU6IBD3Y3oOx7g/YDmN6hNq0ekpCQB9CfI=; b=gGGOrdh0vn+fpEfJQhcg2VyX9sUTRtLoiEX41rR1D1CSftEkXhED/1UZS9VwZVCxRGhXow FTk8bRFtGTZGCSVSy4w2jfivYnsA7/kex7GH2/FRs2DkDHf8aviqjCEK8J370Ud/ayi3KA nGgaqkoqsf+DRUVb4BgiP/U9XdBxG3Uad/OFNPZ3LZTVvp2j04uB8+x3OFwkbh3PuAqUOQ iEnOWwLkZ7c/dgla0rIkVGMoRh6nDp8wQepdRwIEmVhj3SGQyj1PN4qBVcKMA+FCDkN96N 7pRy4NUpd88MQWQgZ3lIDq+WH5S/UKSMTkB0cFvCQfb6VMSSmPdRFNzu5MolPg== Subject: Re: Speculative: Rust for base system components To: freebsd-hackers@freebsd.org References: From: Brian Neal Message-ID: <7d7bc47d-04cf-2f9b-00a3-e3d9d92b3623@aceshardware.com> Date: Mon, 31 Dec 2018 20:04:32 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 055E26A262 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aceshardware.com header.s=dkim header.b=gGGOrdh0; dmarc=pass (policy=none) header.from=aceshardware.com X-Spamd-Result: default: False [-3.96 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[aceshardware.com:s=dkim]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[aceshardware.com:+]; DMARC_POLICY_ALLOW(-0.50)[aceshardware.com,none]; MX_GOOD(-0.01)[mail.aceshardware.com]; R_SPF_NA(0.00)[]; NEURAL_HAM_SHORT(-0.89)[-0.895,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.26)[ipnet: 52.52.0.0/15(0.02), asn: 16509(-1.22), country: US(-0.08)]; ASN(0.00)[asn:16509, ipnet:52.52.0.0/15, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Tue, 01 Jan 2019 03:04:13 -0000 This is a good read on some of the pitfalls of Rust: https://hackernoon.com/why-im-dropping-rust-fd1c32986c88 In terms of performance, take a look at Rust on godbolt...a quick test I just ran with a trivial program that sums up a sequence of odd numbers is 29 instructions in C on clang 7.0 and a whopping 137 (!!!) on rustc 1.31.0! Crazy... On 12/30/2018 6:18 PM, 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. > > 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. >