Rust is mostly safety
Dec. 28th, 2016 11:44 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
graydon2Steve Klabnik recently writes that "Rust is more than safety"; in this post he argues that Rust's "marketing pitch" focuses too much on safety, and that that topic doesn't really resonate with everyone.
I'll grant that if one's goal is strictly to expand the market for Rust, it might be worthwhile looking at other strengths that might appeal to other users who don't care about "systems languages" + "safety". And there is, of course, a lot to love in Rust besides its safety features. We actively reproduced that which was tasteful and powerful from other languages. The traits system of bounded polymorphism and existentials is a delight. The classical ML-style algebraic types and patterns are as wonderful as ever. The expressive and flexible compilation model, along with a first class package manager, is a breath of fresh air in systems work.
And yet. And yet.
There is part of me that winces when someone goes looking for a justification for Rust above and beyond safety. Safety in the systems space is Rust's raison d'être. Especially safe concurrency (or as Aaron put it, fearless concurrency). I do not know how else to put it. When someone says they "don't have safety problems" in C++, I am astonished: a statement that must be made in ignorance, if not outright negligence. The fact of the matter is that the further down the software stack one goes, the worse the safety situation gets. Our engineering discipline has this dirty secret, but it is not so secret anymore: every day the world stumbles forward on creaky, malfunctioning, vulnerable, error-prone systems software and every day the toll in human misery increases. Billions of dollars, countless lives lost. Can one really say "I don't have safety problems" in systems programming?
I do not mean to pick on C++: the same problems plague C, Ada, Alef, Pascal, Mesa, PL/I, Algol, Forth, Fortran ... show me a language with manual memory management and threading, and I will show you an engineering tragedy waiting to happen. I do not think it is too unfair to say that if Rust provided nothing but safety upgrades to the systems space, it would have been worth all the time and energy. And it has been the overriding design priority from the very beginning: no wild pointers, no null pointers, no shared mutable state. Take a look at the very first slide deck. That's what Rust has always been about: bringing safety features to the systems niche, a niche that has stubbornly resisted them for decades while higher-level languages have moved ahead in safety.
A few valiant attempts at bringing GC into systems programming -- Modula-3, Eiffel, Sather, D, Go -- have typically cut themselves off from too many tasks due to tracing GC overhead and runtime-system incompatibility, and still failed to provide a safe concurrency model.
Rust's success in raising the bar for safe, concurrent systems programming -- in ways that the niche finds usable, performant and compatible -- cannot (imo) be overstated. That is its purpose, and that has been its great success.
I'll grant that if one's goal is strictly to expand the market for Rust, it might be worthwhile looking at other strengths that might appeal to other users who don't care about "systems languages" + "safety". And there is, of course, a lot to love in Rust besides its safety features. We actively reproduced that which was tasteful and powerful from other languages. The traits system of bounded polymorphism and existentials is a delight. The classical ML-style algebraic types and patterns are as wonderful as ever. The expressive and flexible compilation model, along with a first class package manager, is a breath of fresh air in systems work.
And yet. And yet.
There is part of me that winces when someone goes looking for a justification for Rust above and beyond safety. Safety in the systems space is Rust's raison d'être. Especially safe concurrency (or as Aaron put it, fearless concurrency). I do not know how else to put it. When someone says they "don't have safety problems" in C++, I am astonished: a statement that must be made in ignorance, if not outright negligence. The fact of the matter is that the further down the software stack one goes, the worse the safety situation gets. Our engineering discipline has this dirty secret, but it is not so secret anymore: every day the world stumbles forward on creaky, malfunctioning, vulnerable, error-prone systems software and every day the toll in human misery increases. Billions of dollars, countless lives lost. Can one really say "I don't have safety problems" in systems programming?
I do not mean to pick on C++: the same problems plague C, Ada, Alef, Pascal, Mesa, PL/I, Algol, Forth, Fortran ... show me a language with manual memory management and threading, and I will show you an engineering tragedy waiting to happen. I do not think it is too unfair to say that if Rust provided nothing but safety upgrades to the systems space, it would have been worth all the time and energy. And it has been the overriding design priority from the very beginning: no wild pointers, no null pointers, no shared mutable state. Take a look at the very first slide deck. That's what Rust has always been about: bringing safety features to the systems niche, a niche that has stubbornly resisted them for decades while higher-level languages have moved ahead in safety.
A few valiant attempts at bringing GC into systems programming -- Modula-3, Eiffel, Sather, D, Go -- have typically cut themselves off from too many tasks due to tracing GC overhead and runtime-system incompatibility, and still failed to provide a safe concurrency model.
Rust's success in raising the bar for safe, concurrent systems programming -- in ways that the niche finds usable, performant and compatible -- cannot (imo) be overstated. That is its purpose, and that has been its great success.
no subject
Date: 2016-12-29 10:44 pm (UTC)no subject
Date: 2017-01-01 04:24 am (UTC)(Also: the safety upgrades Rust provides are really just the tip of a much larger iceberg of safety tech I'd love to see people porting more widely into systems software. The things hardware people routinely check -- rich combinations of decidable 1st order theories, temporal properties, etc. -- are way outside what most of our deployed systems-level type systems check. But they shouldn't be! Many of the programs we write are no more "uncheckable" in principle: they're doing "finite-state-machine-like" things and should be much, much more thoroughly locked down and checked than they are, even when written in Rust.)