DevelopmentSubsection
Backend
Five runtimes, described by the one thing that actually differs between them: how each handles concurrency. Not syntax, not ecosystem size, not benchmarks — the execution model, because that is what decides which problems a language makes easy and which it makes expensive. Read two of these side by side and most "which language should we use" arguments answer themselves.
What is inside
Every page in this group, with what each one covers.
- PHPA process per request that starts clean and ends clean — the model that makes PHP simple to reason about and hard to keep state in.Per requestShared nothing
- JavaThe JVM as the actual product: memory model, garbage collection, JIT, and what virtual threads changed.JVMThreads
- Node.jsOne thread doing the work and a pool doing the waiting — why Node is excellent at I/O and poor at arithmetic.Event loopNon-blocking
- PythonThe GIL explained properly: what it does and does not prevent, and which of the three workarounds fits your workload.GILasyncio
- GoGoroutines and the scheduler underneath them: cheap concurrency, and the places where cheap stops being free.GoroutinesScheduler
Where to start
- Choosing a runtimeRead the two you are choosing between and compare the concurrency models. Everything else is negotiable; that is not.
- Your service is slow under loadYour runtime’s page. Almost every load problem is the workload fighting the execution model rather than a lack of hardware.
- Coming from another languageRead your old runtime and the new one together — the difference between the two models is the thing to internalise.
Elsewhere in the section
- DevelopmentSoftware development is the work of deciding where the boundaries in a system go, what runs on each side of them, and what moving one of those boundaries will cost once the code is live. This section covers 28 topics — architecture, the browser, five backend runtimes, four mobile platforms, language models and the databases underneath all of it. Every page turns on the constraint that actually separates the options, rather than on the API surface.
- ArchitectureWhere to put the boundaries, and what each boundary costs. Four topics: the two shapes a system can take, the migration between them that most teams attempt at the wrong moment, and the contract that makes any boundary usable by somebody else. The recurring theme is that a boundary is not free — it buys independence and charges you in latency, debugging and operational surface.
- DatabasesWhere the state lives, and what each store guarantees about it. Three topics: how a relational engine actually answers a query, what a non-relational store trades away to scale, and how to design a schema that will still be true in three years. Modelling comes last on purpose — it is the one that determines whether the other two are easy or painful.
Found this useful?
Share it with someone who is working on the same problem.