Why did we chat with Steve this week? Because he'll be speaking at All Things Open this week; because Rust is getting a lot of buzz; and because 'systems programming in something Haskelly' sounds beautiful, terrifying, and reassuring all at once.
A Bit About Steve
Rust is no ordinary language, and Steve is no ordinary coder. He started programming at age ten, studied OS design in college, then nearly rhizomed his way into ivory-tower academia via graduate studies in English. These days most modern language departments in the United States basically study philosophy, or sociology, or linguistics, or political science, or any one of a dozen disciplines whose concrete objects are probably written in the language associated with the department. In other words, 'English' is a cover for Deep Thought; and Steve's career trajectory in software engineering says that he really hasn't stopped thinking deeply.
So what does a 'deep thinking' software engineer do? Simple: work with Rails, make it better, dig beyond the MVC, through the ORM, past the hand-holding until you're back to the metal, thinking about what the computer is actually computing. For Steve, the adventure to von Neumann was also a homecoming: during our interview he described his interest in Rust as a return to the world he used to participate in (when he built OSes in college using C and its offspring).
Rust is Shiny (and Safe)
I haven't used Rust. I've played with C but it's a little scary outside of play-land -- don't want to turn into the next Heartbleeder or Shellshocker (and Aleph One's famous piece is so readable that someone is sure to smash any stack my totally-compilable C code creates). Rust's promise?
Rust is a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety.
Well, okay, rust-lang.org, that's what you say. But let's be specific: what exactly makes Rust safe -- given that it does allow direct memory access?
Steve (who also writes the superb official Rust documentation) gave a quick answer during our chat. The compiler follows specific rules to prevent unplanned memory access, namely:
iterator invalidation (Rust lets you refer only to immutablevectors within loops)
buffer overflow (the Rust compiler won't compile code that doesn't assign strict ownership of every memory address at all times)
use after free (all resources have definite lifetimes)
The design philosophy is thus, roughly: instead of making the language designers get the compiler to figure out where you aren't writing memory-safe code, it's the programmer's job to prove to the compiler that her code is memory-safe. Taking the same approach to sanitizing inputs: it's a lot easier to write an allow regex than a reject regex, because the former possibility space is controlled while the latter is unbounded. Anything you can get a compiler to check, you should get a compiler to check. (For more on Rust's ownership system check out Steve's triptych in the official docs.)
Now, there are ways to get around these checks -- just as even the comparatively-paranoid garbage-collecting Java platform still includes the (officially undocumented) sun.misc.Unsafe API (although not for much longer). But, Steve notes, these are rarely useful, and most situations in which such less-controlled DMA might be useful are covered in existing libraries.
There's a Reason They Call It Thread Safety
Think about the memory-management rules above. Yes, they block exploits; but memory access issues are behind most concurrency problems, too. Think of a race condition (say, for the balance in a bank account); then consider, "What if that account balance had just one owner at all times?" Then it wouldn't matter if Some Non-Owner hit the resource first. Outcome predictable; race condition nullified.
Details on concurrency in Rust are a bit more complicated, of course, and Steve can explain them much better than I can.
In some sense that I don't fully understand (but hopefully will learn at ATO!) Rust achieves safety through an unusually sophisticated approach to types. (Type theory describes both language design and maybe even all of mathematics at the very deepest levels. Typically compsci-deep stuff, like Lisp, is very far from processor-deep stuff, like assembly or C..but now with Rust we can have both, hmm...)
You, Too, Can Do Systems Programming
All this sounds neat, but maybe a little intimidating to us poor memory-managed actually-get-the-job-done-faster-than-building-an-OS developers. Or anyway that's kind of how I reacted when Steve began to explain Rust's compiler rules.
But don't worry, he says: Rust is actually super-friendly for systems programming newbies (fine, like me). The Rust documentation has very concrete introductions to stacks and heaps and the use of Rust in other languages. I'm reading Bryant and O'Hallaron's wonderful Computer Systems: A Programmer's Perspective right now, and of course there's always the classic K&R.
In fact, the three things that most excite Steve about Rust today might help ease the transition both to Rust in particular and to systems programming in general. The first, scoped threads, simplify (and safe-ify) concurrent programming by allowing you to reference parent stack frames safely. The second, the Rumprun unikernel, lets you write POSIX-compliant applications without relying on the whole standard Rust library. The third, a formalization of Rust's semantics, will make formal proofs (or disproofs) of Rust's safety promises possible, which should (assuming positive results) give developers enough confidence in the compiler checks that they don't need to worry about the details.
But again I hear Steve's Introduction to Rust will cover some of this ground too. So if you're in Raleigh on October 19-20 (yay next week) you should totally go to his talk. Steve isn't the only awesome speaker, and we'll be there with a booth and a few hundred prettily printed Guides (that we're giving away for free). We've even got a 20% discount code -- DZONE20 -- and registration is already pretty cheap anyway. We should all hang out and learn about safe systems programming and a hundred other topics over a nice iced tea.