My journey to Rust
When I started my professional career as a programmer 16 years ago, I knew some C, C++, Java and a bit of x86 assembly but it didn't take long before I completely forgot most of what I knew of C++ and Java, and completely focused on C. There were a few difference reasons that contributed to that:
- Working with very limited embedded systems (I'm talking 8051) at that time, I quickly became obsessed with performance and C was my best bet if I didn't want to write all my code in assembly.
- Shortly before I graduated, I got involved in GStreamer project and became a fan of GNOME and Gtk+, all of which at that time was in C. Talking to developers of these projects (who at that time seemed like gods), I learnt how C++ is a bad language and why they write everything in C instead.
- An year after graduation, I developed a network traffic shaping solution and the core of it was a Linux kernel module, which as you know is almost always done in C. Some years later, I also wrote some device drivers for Linux.
So I've been passively and sometimes actively seeking a better programming language for more than a decade now. I got excited about a few different ones over the years but there was always something very essential missing. The first language I got into was Lisp/Scheme (more specifically Guile) but the lack of type declarations soon started to annoy me a lot. I felt the same after then about all scripting languages, e.g Python. Don't get me wrong, python is a pretty awesome language for specific uses (e.g writing tests, simple apps, quick prototyping etc) but with lack of type declarations, any project larger than 1000 LOCs can quickly become hard to maintain (at least it did for me).
Because of my love for strong-typing, C# and Java did attract me too briefly. Not having to care about memory management in most cases, not only helps developers focus on the actual problems they are solving, it indirectly allows them to avoid making very expensive mistakes with memory management. However, if developer is not managing the memory, it's the machine doing it and in case of these languages, it does that at run time and not compile time. As a C developer and a big hater of waste in general, that is very hard to be convinced of as a good idea.
There was another big problem all these high-level languages: you can't nicely glue them with the C world. Sure you can use libraries written in C from them but the other way around is not a viable option (even if possible). That's why you'll find GNOME apps written in all these languages but you will not find any libraries written in them.
Along came Vala
So along came Vala, which offered features that at that time (2007-2008) were the most important to me:
- It is a strongly-typed language.
- It manages the memory for you in most cases but without any run time costs.
- It's high-level language so you avoid a lot of boilerplate.
- GNOME was and still is the main target platform of Vala.
- It compiled to C, so you can write libraries in it and use them from C code as if they were written in C. Because of GObject-introspection, this also means you can use them from other languages too.
- Firstly the success of Rust is not entirely dependent on one very specific project or a tiny group of people, even if until now most of the development has been from one company. Ever month, you hear of more communities and companies starting to depend on Rust and that ensure it's success even if Mozilla was to go down (not that I think it's likely) or stopped working on it. i-e "it's too big to fail". If we compare to Vala, the community is a lot bigger. There are conferences and events happening around the world that are entirely focused on Rust and there are books written on Rust. Vala never came anywhere remotely close to that level of popularity.
When I would mention Vala in job interviews, interviewers would typically have no idea what I'm talking about but when I mention Rust, the typical response is "Oh yes we are interested in trying that out in our company".
- While Vala is already a safer language than C & C++, you still have null-pointer dereferencing and some other unsafe possibilities. Safety being one of the main focus of the language design, Rust will not allow you to build unsafe code, unless you mark it as such and even then, your possibilities of messing up are limited. Marking unsafe code as such, makes it much easier to find the source of any issues you might have. More over, you usually only write unsafe code to interface with the unsafe C world.
This is a very important point in my opinion. I really do not want to live in a world where simple human errors are allowed cause disasters.
- Ability to easily write GObjects.
- Creating shared libraries.
Should we stop writing C/C++ code?
I am excited about Rust and I'm hopeful the future is much safer thanks to people behind it. Happy holidays and have a fun and safe 2018!