What is Rust? Part 1: What is a Programming Language?

The fast, safe, super difficult to write programming language that’s finally getting its flowers.

Rust is a statically-typed, compiled programming language that enforces memory safety through -- *record scratch*

Woah woah woah. Let’s back up.

What is a programming language?

Computers have the notable distinction of being at once one of the most intelligent inventions in human history and also being super dumb. They can technically do almost anything, but only if you tell them exactly what to do in exactly their language – the language of 1s and 0s.

See, a computer is a bundle of physical circuits that can be open (represented as 0) or closed (represented as 1), and all the data a computer uses and all the logic it performs is articulated to it in the language of 1s and 0s called binary; the OG programming language. It’s just ones and zeros all the way day.

Writing complicated logic with only two numbers at your disposal is obviously hard. Accordingly, telling computers what to do was a massive pain for many many years, so much so that it was generally confined to the domain of nerds at universities like Grace Hopper and Ada Lovelace. They’d write out the literal 1s and 0s the hardware understood, sometimes by physically flipping switches or feeding in stacks of cards with holes punched in them. This was, as you might expect, difficult, error prone, and a pretty far cry from the work you see modern software engineers doing at the specialty coffee shop.

🐛 Bug Report

The term “bug” in software traces back to 1947, when Grace Hopper’s team found an actual moth stuck in their Harvard Mark II relay computer. They taped it into the logbook with the note “first actual case of bug being found.”

As these early computer scientists wrote more code, they realized a lot of their code did the same things, like adding two numbers or storing a name, and they concluded they needed an easier way to write these common instructions. They landed on the idea of a “higher level” programming language that read like English, which would then be run through a translator called the compiler that turned it into 1s and 0s for the machine. Easy for humans to write, easy for computers to run, everybody wins! Thus the first mainstream programming language was born: FORTRAN.

Confusion alert: when we talk about “high level” and “low level” languages, we’re not making a dig at lower level languages. It’s about abstraction. At the lowest level you have binary ones and zeros, the actual language of the machine. Assembly sits one rung above that, giving human-readable names to those same operations. Each “higher” layer up the stack abstracts away more of the underlying detail, trading fine-grained control for readability and ease.

Why are there so many programming languages?

We don’t talk about programming languages much here at Technically because, well, for the purpose of understanding the world of tech at a high level, we don’t really think it matters. Most languages are more alike than they are different, and they all do basically the same things give or take a few things. So, why even have more than one language? You just said computers only speak 1s and 0s right and so we made FORTRAN to solve that. Why do developers today write in over a hundred of them?

The answer is in tradeoffs. Since a language is a layer on top of 1s and 0s, each one makes slightly different design decisions on its journey to being English-like. The authors of FORTRAN made a thousand little judgment calls on your behalf. What gets to be easy and what stays hard? What happens automatically and what do you have to spell out by hand?

Some of FORTRAN’s decisions people liked, others they didn’t. So they wrote a different language, and then another, and then another, and each of these human-friendly programming languages prioritizes something different at the expense of something else. There is no best language, there is only the spectrum on which a host of tradeoffs sit.

For the purposes of understanding the wonderful world of Rust, we’re going to zoom in on one specific tradeoff: memory.

A trip down memory lane

When a program (some code) runs, it needs somewhere to keep the stuff it’s actively working with like:

• The user’s name

• The current score of your little game

• The contents of the text box you’re typing in right now

This is what memory is for. You can think of it as the program’s desk; not long-term storage like a filing cabinet (that’s your hard drive), but the open workspace where things sit while you’re actually using and working with them.

The desk needs to be managed: periodically cleaned and organized. After all, it’s small, and the program never stops working. In practice this means setting new data down, grabbing data back when it’s needed, and clearing off the old stuff to make room. This is the harrowed discipline of memory management.

There are lots of different ways to manage memory. Some approaches prioritize speed, and others deliver safety.

• By speed, I mean exactly what it sounds like. How fast the program runs. How quickly the page loads, how little the game stutters, how fast the trade goes through.

• By safety, I mean how well the language stops you from hurting yourself. A safe language makes it hard to write the kind of bug that crashes the program, leaks private data, or hands an attacker a way in. An unsafe language trusts you to never screw up, which, reader, you will.

By way of example, many higher level languages, like Python, manage memory for you automatically. That makes them safe and forgiving, but it costs in terms of performance because the program is spending energy doing memory housekeeping chores in the background while it runs. I.e. Python is considered slow.

Many lower-level languages, like C, are wicked fast because they don’t do any automatic memory management, but that means they’re hard to write (you have to manage the memory yourself) and prone to failure.

There are other tradeoffs inherent in different programming languages too, which won’t be the focus of this series, but are worth mentioning:

• Static vs. dynamically typed. Does the language require you to declare what kind of data every variable holds (a number, a word, true/false) before it runs? Static typing catches bugs early but is more rigid to write. Dynamic typing is faster and looser to write, but errors show up at runtime in production, where they hurt.

• Compiled vs. interpreted. Does the translation from code to binary happen upfront, or on the fly? Compiled languages do it all before the program runs, producing something fast and optimized. Interpreted languages translate as they go, which makes them more flexible and easier to experiment with, but slower when running.

• Ecosystem. A language comes with a community, a library of pre-built tools, and a job market. Python dominates data science not because it’s the fastest language (it isn’t) but because the tooling built around it is so mature that nothing else comes close.

In any case, the memory tradeoff often ends up being the big one - the granddaddy of them all, the primary question a developer must ask themselves before embarking on a new engineering expedition: Do you want it fast or do you want it safe? Which way western man?

You might be wondering why memory in particular is so important, such that (as I’ll demonstrate) someone built an entire new language around making working with it better. In part two, we’ll go deeper on why the memory problem is more consequential than ever in the age of high speed trading, AI, and online gaming, and what one cracked engineer at Mozilla decided to do about it.