What kinds of problems does this language make unusually natural to solve?

Section 1How the curriculum is delivered

Written in full, these five courses are the size of a book. Delivering them as one document would mean losing exactly the parts that make them worth reading: the line-by-line explanations, the exercises, the debugging sections. So each course is split into instalments — this curriculum map, then five self-contained documents per course, each readable on its own. Every instalment ends with a button to the next one, so you can move through a whole course, or the whole curriculum, by clicking forward.

The instalment sequence, and how far each course currently reaches:

Instalments are numbered continuously across the whole curriculum — each one says which number it is, and what's next, in a footer at the bottom. If you'd rather reorder the courses themselves — for example, taking Erlang immediately after Go so the two concurrency models sit side by side — nothing here enforces the numbered order; jump straight to that course's instalment from the links at the end of this page.

Section 2Overview of the five courses

Each course is built around one question that the language answers unusually well. The project exists to force you into that answer.

There is a deliberate pairing structure. Go and Erlang are both about concurrency and disagree profoundly about how to get it. Ruby and Racket are both about growing a language toward the problem and disagree about whether you do that at run time or compile time. Perl stands alone as the Unix-shaped view of computing: a program is a filter, text is the universal interface.

Section 3Prerequisites

What you need to already know

• General programming. Variables, functions, recursion, data structures, complexity, why a hash map is fast. You have written a few thousand lines of something.
• A terminal. cd, ls, pipes, redirection, environment variables, editing PATH. The Perl course leans on this heavily; the others assume it.
• Git. Enough to commit per milestone, which I will ask you to do, because the diffs are part of the learning.
• An editor you are fast in. Each course tells you how to wire up the language server.

What you do not need

Any prior exposure to these five languages, functional programming, actor models, compiler theory, or distributed systems. Every term gets defined when it first appears. Where a concept is genuinely hard (hygiene in macros, split-brain in distributed systems) it gets its own section rather than a parenthesis.

Machine and environment

• Any machine from the last decade with about 10 GB free. The Go and Erlang projects spawn tens of thousands of lightweight tasks, which is a memory question rather than a CPU question, and 8 GB of RAM is plenty.
• macOS, Linux, or Windows. Commands are given for all three. On Windows, WSL2 (Windows Subsystem for Linux) is strongly recommended for the Perl and Erlang courses, and optional for the rest. Native Windows instructions are included where they differ.
• Docker is optional throughout. The distributed stages of Go and Erlang work fine as multiple processes on one machine.

Time

Roughly 180–260 hours for all five if you do the exercises rather than reading past them. At six hours a week that is about a year. At fifteen it is about four months. Doing one course properly beats skimming five.

Section 4Recommended order

The courses are numbered as you listed them, but the order I recommend studying them in is different:

  Go  ──────────►  Erlang  ──────────►  Ruby  ──────────►  Racket
  (1)               (4)                  (2)                (5)
   │                                                          
   └── Perl (3) fits anywhere; it shares no concepts with the others

The reasoning:

• Go first. Its syntax is the least surprising of the five, its tooling is the best, and its error messages are the kindest. You spend your energy on concurrency rather than on the language.
• Erlang second, while Go is fresh. The moment you have hand-written a supervisor goroutine that restarts crashed ants, Erlang's supervision trees land as "oh, this is built in, and thought through far more carefully than mine". That contrast is worth a great deal and it fades if you wait a year.
• Ruby third. After two courses of systems thinking, a course about expressiveness is a real change of gear. It also introduces DSL design at run time.
• Racket fourth. Racket is the same ambition as the Ruby course pushed to its conclusion: the Ruby DSL is a library pretending to be a language, and Racket makes it an actual language. Having felt the limits of the Ruby approach makes macros feel necessary rather than clever.
• Perl whenever. It depends on nothing and nothing depends on it. It is a good palate cleanser after Erlang, and a good warm-up if you want an easy start.

If you would rather work strictly in the numbered order, nothing breaks. The Ruby-then-Racket connection is the only one I would try to preserve.

Section 5Difficulty and learning goals

Four different kinds of difficulty, rated 1 (easy) to 5 (hard), because they are not the same thing. A language can have easy syntax and a brutal conceptual model, or the reverse.

Notes on the ratings. Go's concept score is entirely concurrency; the rest of the language is deliberately small. Perl's syntax score is high because of sigils and context, a rule that has no equivalent in most languages, and its debugging score is high because a typo can be silently valid. Erlang is hard on every axis at once: unfamiliar syntax, an unfamiliar build tool, and a model that asks you to unlearn defensive programming. Racket's syntax is trivial to read after an hour, and its concept score comes entirely from macros and phase separation.

Learning goals, stated as things you will be able to do

• Go: design a concurrent system where ownership of data is explicit; read a race detector report and fix the cause; shut a system down cleanly under load; profile and find the actual bottleneck.
• Ruby: design an internal DSL that reads like a language, is testable, produces an inspectable intermediate representation, and can be extended by third parties without editing your source.
• Perl: build a streaming data pipeline that survives malformed input, correlates records across sources, and runs as a well-behaved Unix citizen.
• Erlang: design a supervision tree; choose restart strategies with reasons; reason about what happens during a network partition; observe a live system without stopping it.
• Racket: implement an interpreter, then a compiler, for a small language; write hygienic macros with good error messages; ship a working #lang.

Section 6Detailed syllabi

Each course follows the same shape: Part 0 (what we are building), Part 1 (install and first program), Part 2 (language crash course), then twelve milestones, then an advanced phase, a final challenge, and a knowledge check. Below is the milestone plan for each.

Course 1 — Go: Digital Ant Colony

Course 2 — Ruby: Programmable Automation DSL

Course 3 — Perl: Text Archaeologist

Course 4 — Erlang: The Internet That Never Dies

Course 5 — Racket: Language Factory

That's the whole curriculum. Go is first, so its instalment picks up next: what we're building (an ant colony that finds itself corrupting its own state the moment it goes concurrent, and the idiom that fixes it), installing the toolchain, and a full language crash course, before Milestone 1 begins.