0.2Introduction to programs and languages
Modern computers are absurdly fast. The processor in an ordinary laptop can perform billions of operations per second. What it can't do is figure out what you meant. A computer only does precisely what it's told, one small instruction at a time.
A program is a set of instructions that tells a computer what to do. Programming is the act of writing those instructions, and the text you write is called source code (or often just code). When a computer carries out the instructions in a program, we say it runs or executes that program.
Programs are software: instructions and data, no physical form. The machinery that runs them (processor, memory, screen, the box itself) is hardware. The hardware that matters most for this lesson is the CPU (central processing unit), the chip that actually executes a program's instructions.
So what do the instructions a CPU understands look like? Not like anything you'd want to write.
Machine code
A CPU executes machine code: instructions encoded as raw numbers, which we usually picture as binary, long strings of 1s and 0s. For example, on an x86 processor (the family of chips in most desktop PCs), these sixteen bits are one complete instruction:
10110000 01100001It tells the CPU to copy the value 97 into one of its internal storage slots. Riveting stuff. And that's one of the short instructions; a real program contains millions of them.
The very first programmers wrote machine code by hand. Beyond being miserable to write and nearly impossible to read back, machine code has a deeper problem: each CPU family has its own instruction set. A program written as machine code for an x86 chip is gibberish to the ARM chip in your phone. Machine code is the least portable form a program can take.
Assembly language
The first big improvement was assembly language, which replaces the raw numbers with short, human-readable abbreviations. The instruction above, written in x86 assembly, looks like this:
mov al, 97That reads as "move the value 97 into the register named al" (a register is one of those internal storage slots: a tiny, extremely fast piece of memory inside the CPU). Since the CPU itself only understands machine code, a translator program called an assembler converts assembly into the equivalent machine code.
Better. But assembly is still a one-abbreviation-per-instruction affair: doing anything interesting takes pages of it, the programmer still has to think in terms of registers and memory addresses, and each CPU family still has its own assembly language. The portability problem hasn't moved an inch.
For advanced readers
Assembly hasn't disappeared. It's still used where exact control over the CPU matters, like the innermost loops of video codecs and cryptography libraries, and being able to read a little assembly remains a useful (if niche) skill for understanding what your compiled code really does. Nobody writes whole applications in it anymore.
High-level languages
To free programmers from thinking like a particular chip, high-level languages were invented. Rust is one. So are C, C++, Python, Java, JavaScript, and essentially every other language you've heard of. In a high-level language, the work of that assembly instruction is just:
let a = 97;One readable line, and notice what it doesn't say: no register names, no memory addresses, nothing about which CPU family you're on. You describe what should happen; figuring out the chip-specific details becomes the computer's job.
That translation happens in one of two ways. A compiler reads your entire source code and translates it ahead of time into a ready-to-run program (typically an executable file full of machine code). You can then run that executable as many times as you like. The source code isn't needed anymore, and neither is the compiler. Alternatively, an interpreter translates and executes source code on the fly, every time the program runs, with no executable produced. Interpreted programs are flexible to develop but pay a price: the translation work is redone on every run, so they tend to start slower and run slower.
Rust is a compiled language. When your Rust program runs, it runs as native machine code, with no interpreter in the middle. That's a big part of why Rust programs are fast. Python and JavaScript are the best-known interpreted languages.
For advanced readers
The line is blurrier in practice: modern JavaScript engines compile hot code while the program runs (just-in-time compilation), and Java compiles to an intermediate bytecode that's then JIT-compiled. The clean compiled/interpreted split is a simplification, but it's the right one for understanding where Rust sits.
High-level languages also solve the portability problem, with one catch worth understanding. Your Rust source code is portable: the same .rs files can be turned into programs for Windows, macOS, Linux, or that ARM chip in your phone. The executable the compiler produces is not portable: it's machine code for one platform. So you don't write the program three times; you compile it three times. (How you'd actually do that is a story for much later. For now: write once, recompile anywhere.)
The boxes you'll see everywhere
Throughout these tutorials, certain kinds of advice get pulled out of the main text into colored boxes, so they're easy to spot and easy to find again later. Here's the full cast:
Best practice
The recommended way to do something. When there are several ways that work, this is the one to default to. Doing things the standard way makes your code easier for others (and future you) to read.
Warning
A common mistake or trap. These boxes exist because generations of new programmers have stepped on exactly this rake.
Tip
A nicety: a shortcut, a convenience, something that makes your life easier but that you could live without.
Key insight
The why behind a rule. These boxes are the ones to re-read when a rule feels arbitrary. Rust has reasons, and knowing them makes the rules far easier to remember.
For advanced readers
Optional depth for readers who want it (you've met two of these already in this lesson). Skipping every one of these boxes costs you nothing; the main line of the course never depends on them.
In the next lesson, we'll look at the language this course is actually about: where Rust came from, what it's for, and why it's worth your time.