I recently stumbled on to the Rust programming language.
What struck me was the promise of safety and performance – a C for the rest of us is the customer pitch.
And indeed Rust is a nifty programming language that tries to bridge a gap between managed code and unmanaged code. Managed code is code that has system managed memory, aka garbage collectors, and unmanaged code is code that relies on the programmer to manage the code directly.
Conceptually what they are doing is using the type system to enforce safety. This restricts what kinds of things you can do with pointers, but if the type system forbids certain activities then that’s okay and your program can fit into that model that’s okay as well.
There are papers from 15 years ago that explored this kind of concept: CCured: Type-Safe Retrofitting of Legacy Software – Rust almost represents a natural evolution of this thought process – don’t try to make an unsafe language safe, let’s try to make a language safe while retaining the ability to manage memory directly.
What is intriguing about Rust and what differs from the papers I remember reading so many years ago when I was a student at Stanford is that they are tackling the problem differently. Instead of asking: How do I make C safer? They are asking: How do I make it easier for Ruby programmers to write code that has memory that is unmanaged? Essentially they are posing the question – do we need garbage collectors at all? And if we don’t then that may have profound implications for how code gets written.
And as it turns out that the problem of enabling Ruby programmers to write unmanaged code is far more important to solve than the problem of making C safe, and I might even argue tractable.
What is fascinating is that since the early late 90’s the need for a language that fits between the need to actually manipulate direct memory regions and completely managed code remains and that space needs to get filled and Rust is a credible player in that space.
Leave a Reply