Since the 1970’s C (and later its derivatives like C++) have become the main programming languages used in systems and platform programming, but is that about to change?
C/C++ came to dominate over other languages because it exceeds the 80/20 rule; with well written C/C++ you can get well over 80% of the efficiency of hand crafted assembly language in less than 20% of the development time. However every C/C++ programmer has seen their ‘perfectly’ crafted and tested program crash at the most embarrassing time possible, due to some unexpected issue in memory allocation or mishandling of a pointer.
So is there an alternative that can reduce this? An alternative that might relegate C/C++ to very limited areas of the industry, in the same way as we see assembly language used today? We have seen many new languages pass by without really displacing C/C++ as the systems programming language, but is it possible that Rust might be the real giant killer?
Before trying to answer this question we need to understand a little of what the Rust programming language actually is.
Rust is designed to be a ‘safe, concurrent, practical language’ and it is supported by an open (and friendly) community. Rust is sponsored by Mozilla Research, so it has a strong backer and it is unlikely to disappear through lack of support. We at Cambridge Consultants have been working with Rust for a little while, and indeed my colleague Jonathan Pallant gave a positive talk on it in October of last year.
The initial Rust development started back in 2009, with the first stable release appearing in 2015, and a number of updates are released each year. Rust provides a number of high level constructs found in many scripting languages, but it is statically typed and compiled so it can execute as fast as any native language.
As a programmer, who sometimes still uses assembly code to get that extra speed, I have to admit that I was sceptical; you simply can’t use a ‘safe’ language in some areas of system programming. However when I started looking at Rust I found this language design philosophy was applied in a very practical way; what Rust means by ‘safe’ is that the default behaviour is the safe option, but still the programmer has the power to override this where it is necessary.
A trivial example of this is that in C/C++ all variables are mutable by default and you add the const keyword to make them immutable; in Rust all variables are immutable, and you add the mut keyword to make them mutable. The C/C++ programmer in me says that’s a lot more typing, but actually it’s just a small example of a different, safer mind set which you find in the Rust language design. This goes on to having a language keyword - ‘unsafe’; which tells the compiler to release some restrictions in that specific block of code. This keyword also flags areas of the program which need to be checked in more detail during code review and testing; something which is normally achieved by comments in C/C++.
Another area where Rust is helpful is that it handles underlying memory allocation and release of objects, and ensures this is done in a safe consistent way. Again, when I originally saw this I was sceptical, since most languages do this with garbage collectors which cause issues in real time systems. Rust is designed to use reference counting and scoping to implement this in the same way as we would in C/C++. However because it’s part of the language, the compiler can check and catch a number of issues at compile time, rather than finding them from the core dump.
In such a few words I can only start to scratch the surface of the language, and I haven’t even started to describe the infrastructure (such as the package manager Cargo), but I hope I’m sharing a little of the exciting possibilities that this new language might open up.
Does this mean that Rust is the answer to generating perfect programs with no bugs? The short answer is ‘No’. The slightly longer answer is that Rust can’t wave a magic wand which turns bad code into gold, but it does make it much harder for a good programmer to accidentally build some bugs into a program.
So will Rust eat away the dominance of C/C++? Will future generations programming with Rust look back at our programs as we do on those pioneers of the past, who were only able to use assembly language?
The Rust language looks like it has a good design, based on looking at the real work of system programmers, and then providing a set of tools in the language to implement code in a safe way. Rust has passed the first hurdle of being able to build its own compiler, and there is work on using Rust on embedded devices, which is starting to show an interesting potential.
However these are very early days, and Rust has a way to go. For example, the ability of Rust to be used to write an operating system or a complex application for the smallest of devices currently supported by C, is yet to be proven. It’s only when Rust is used in anger in such applications that we can truly understand both the full extent of its potential, and its limitations.
Having watched the rise of C/C++, it seems to me that Rust is currently in the position that C was in during the early 1980’s. At that stage the only ‘specification’ available was ‘The C Programming Language’ by Brian Kernighan and Dennis Ritchie, which had been published in 1978. While C was widely used, the formal industry acceptance was only confirmed by the publication of the C89 standard, more than a decade after that first informal specification.
Rust now has an informal specification in the ‘Rust Programming Language’, and one key indicator of its long term viability and maturity will be a formal standardisation. Over the coming years, possibly even decades, it will be very interesting to see how Rust matures, but like any new language it still has a lot to prove. While I can’t yet say if Rust is the replacement for C/C++, it does look like it may be a contender for that mantle.