Haskell Among Peaks: A Language Comparison
This pilgrimage climbed one particular peak thoroughly. This closing chapter looks out at the rest of the range — nine other languages, what each one is actually for, and where to go read more.
Every language is a set of bets about what to make easy and what to make hard. This book has spent its entire length on Haskell’s bets — purity, laziness, a rigorous type system — in enough depth to actually feel their consequences. This closing chapter does the opposite: a brief, honest look at nine other languages’ bets, not to rank them, but to place Haskell’s choices in context.
Figure: A rough sketch, not a precise measurement — but the shape is real: Haskell sits with the strongest, most rigorous static typing of the group, while still being garbage collected rather than demanding manual memory management.
C
The foundation nearly everything else on this list is built on top of — GHC’s own runtime system (this book’s previous chapter) is itself substantially written in C. No garbage collector, no runtime safety net, direct control over every byte, and a compiler that trusts the programmer completely, for better and worse. Where it shines: operating system kernels, embedded systems, and anywhere the cost of any abstraction at all is unacceptable. Haskell’s entire type-system philosophy — make the compiler catch what C leaves to programmer discipline — is easiest to appreciate by contrast with exactly this language.
C++
C with decades of additions layered on top: classes, templates (genuine compile-time generic programming, structurally closer to Haskell’s own type-level thinking than most C++ programmers realize), and RAII — a resource-management discipline that, like Haskell’s own approach to purity, tries to make “did I clean this up correctly” a property the compiler checks rather than a habit the programmer maintains. Where it shines: game engines, high-frequency trading, and any domain needing C-level performance with more structure than C alone offers.
Java
The language that made “write once, run anywhere” and automatic garbage collection mainstream at enterprise scale. Objects are mutable by default — the near-opposite of this book’s Chapter 5 — but Java shares Haskell’s reliance on a managed runtime handling memory, and modern Java has been steadily importing ideas (records, sealed classes, pattern matching) that read like slow, careful convergence toward algebraic data types. Where it shines: large enterprise systems, Android development, and codebases where “any engineer can maintain this in ten years” matters more than raw expressiveness.
Scala
Base Camp’s own history section already named this one: Scala fuses functional and object-oriented programming deliberately, on the JVM, with algebraic data types, pattern matching, and a type system genuinely comparable to Haskell’s own in ambition. The closest neighbor on this list to Haskell’s own approach — the real difference is Scala’s commitment to JVM interop and OOP integration, where Haskell stays uncompromising about purity throughout. Where it shines: large-scale data processing (Apache Spark is written in Scala) and teams that want Haskell-adjacent rigor without leaving the JVM ecosystem.
Rust
No garbage collector, but also no manual malloc/free — Rust’s ownership and borrowing system enforces memory safety entirely at compile time, a genuinely novel approach philosophically very close to this book’s own central argument: push correctness into the type system, and let the compiler refuse to build the broken program. Rust’s Option and Result types are directly, openly descended from Haskell’s Maybe and Either. Where it shines: systems programming, WebAssembly, and anywhere C++-level performance is needed alongside compile-time memory-safety guarantees C++ can’t offer.
Python
Dynamically typed, famously readable, and the dominant language of data science and machine learning tooling — nearly the opposite of Haskell’s bets on every axis this chapter’s figure plots. Where Haskell asks the compiler to prove properties before a program runs, Python asks the programmer to write tests and trust runtime checks; where Haskell defaults to immutability, Python defaults to mutation. Where it shines: rapid prototyping, scripting, and gluing together the numerical libraries (many themselves written in C) that make Python’s own interpreter speed largely beside the point.
Erlang
Built at Ericsson specifically for telecom systems that must never go down, Erlang’s actor model — lightweight processes, message passing, and a deliberate philosophy of “let it crash” and restart cleanly rather than defensively handle every possible failure — is a genuinely different, equally principled answer to the same concurrency problem Beautiful Concurrency’s STM addresses. Erlang is dynamically typed, a real point of contrast with the statically-typed languages on this list, but its BEAM virtual machine’s fault-tolerance guarantees are still, decades later, close to unmatched. Where it shines: telecom infrastructure (its origin), and any system where staying up matters more than almost anything else — WhatsApp and RabbitMQ are both built on it.
Scheme and Racket
The Lisp family closes a loop this book opened all the way back in Chapter 2. Scheme itself was born directly out of the Lambda Papers — the same Steele and Sussman research program “Back to the Calculus” covered, which took lambda calculus’s three rules seriously enough to build an entire practical language around them, with lexical scoping and mandatory tail-call optimization as first-class design commitments rather than afterthoughts. Racket, Scheme’s most actively developed modern descendant, pushes the family’s oldest idea — code and data share one uniform, parenthesized representation — into a genuine “language workbench,” where defining an entirely new domain-specific language (EDSL’s own chapter, taken to its logical extreme) is a routine, first-class activity rather than a special occasion. Both are dynamically typed, a real point of contrast with Haskell’s own static discipline, and both remain, decades on, one of the clearest demonstrations that “a small core plus macros” is a complete, serious alternative to “a small core plus a rich type system.” Where it shines: teaching the foundations of programming languages (Scheme is the vehicle for MIT’s own classic Structure and Interpretation of Computer Programs), and rapid, code-that-writes-code language experimentation Racket was specifically built to make easy.
Clojure
A modern Lisp with a genuinely different center of gravity from Scheme and Racket: Clojure runs on the JVM (with ClojureScript targeting JavaScript), trading some of Scheme’s minimalism for immutable-by-default persistent data structures and a serious, production-oriented standard library — Rich Hickey’s own stated goal was a practical Lisp for real, concurrent, JVM-hosted systems, not primarily a teaching or research vehicle. Clojure is dynamically typed like the rest of the Lisp family, but its insistence on immutability as the default, not an opt-in discipline, is close in spirit to Immutability’s own argument, just enforced by convention and persistent data structures rather than by a static type system checking it at compile time. Where it shines: JVM-hosted systems wanting Lisp’s expressiveness and macro power without leaving the Java ecosystem’s libraries and tooling behind, and concurrent applications built around Clojure’s own software-transactional-memory-flavored reference types — a genuine, independently-arrived-at cousin of Beautiful Concurrency’s own STM.
Several languages on this list didn’t just take inspiration from Haskell loosely — they borrowed specific, named ideas directly. F#‘s and OCaml’s type systems descend from the same Hindley-Milner lineage Base Camp’s history section traced; Rust’s Result and Option are acknowledged descendants of Either and Maybe; and Scala’s for-comprehensions are a direct syntactic cousin of Haskell’s do-notation, both desugaring to the same underlying >>= chain.
None of this is a ranking. Every language above is the correct choice for some real, specific problem — a kernel driver has no business being written in a garbage-collected language, and a two-day data-analysis script has no business fighting a strict type checker. The genuinely useful question a working programmer asks isn’t “which language is best,” but “which set of bets does this particular problem actually need” — and having climbed one peak thoroughly, as this book’s pilgrimage set out to do, makes that question easier to answer honestly for every peak after it, not just this one.
The pilgrimage that opened with a single ghci> 1 + 1 closes here, looking outward at the wider range it was always part of. Haskell’s bets — purity as a discipline, laziness as a default, a type system that refuses to let a program compile until it can prove certain things about itself — aren’t the only reasonable bets a language can make. They’re simply bets this book has now shown you, thoroughly enough to recognize the same bets, or their deliberate opposites, the next time you meet them somewhere else.