What if you could have your cake and eat it too?#
If you haven't read part 1, go do that, or you might be…rusty...
In I explained why there are so many different programming languages: because languages come with tradeoffs, and everyone wants to choose their tradeoffs differently. We discussed how memory and how it's managed is one of if not the most important of those tradeoffs, and how when it comes to memory management you pretty much need to choose between your program being fast, or your program being safe.
The speed vs. safety thing was always around, but it was ultimately manageable. Slow safe programs were fast enough for most users, and fast unsafe languages could broadly keep up with the speed of attackers trying to exploit any memory-related vulnerabilities that snuck into production.
But the game hath changed. Today, increasingly lag-intolerant consumers rely on massive multiplayer games with millions of concurrent players, trading platforms where a millisecond of latency costs real money, and critical infrastructure that nation-states are actively and effectively hacking. Which begged the question (again): can we have a programming language that is both fast to write and safe from a memory perspective?
Rust is a programming language that says maybe you don't have to choose.
It was created by a Mozilla engineer named Graydon Hoare, started as a personal project in 2006, got picked up by Mozilla as an official project in 2009, and hit its stable 1.0 release in 2015. It was built from scratch to be as fast as C and C++ while making an entire category of bugs impossible to write due to its unique approach to the memory problem.
To understand how Rust pulls this thing off, we need to go a little deeper on memory (again). What does it look like to write in a programming languages that do or don’t require you to manually work with memory?
First, the simpler one. In higher level languages like Python there is something called the garbage collector – a glamorous position if there ever was one. The garbage collector is a sort of “engine” that runs periodically in Python programs to help handle your memory for you. It scans your memory story and cleans it up. And much like a garbage truck if you've ever been stuck behind one while 10 minutes late for something important, it’s slow as hell because garbage collection is a computationally intensive task. Again, tradeoffs.
In a low level language like C, you must manually interact with the memory system, allocating data for each piece in your program. Before you can store a user's birthday to display it to them in an app, you need to allocate a slot for it, and when you are done with the birthday, you need to release the memory. By allocating a slot, I mean literally telling the computer: hey, I need you to store this variable (an allocation), and it will require 8 bytes and data, and you should do it here in particular. And then Mr. Computer, when we are done with this variable, you should delete that data (a release). Like I said, computers both dumb and smart.
This manual process skirts around the garbage truck – which means it’s much faster while running – but it's incredibly time consuming and error prone to write. If you miss an allocation or release anywhere in your code, it's likely your program will crash or be vulnerable to hackers.
Like I said, for what seems like forever these were your two choices. Easy breezy but very slow garbage collection, or rigorous and fast but highly labor intensive (and vulnerable) manual memory allocation. Rust does a third thing.

