Big question. Some glittering generalities: 1. These languages, having been used many times over to write compilers, have been battle-tested. 2. These languag

Big question. Some glittering generalities: 1. These languages, having been used many times over to write compilers, have been battle-tested. 2. These languages do a good job of making immutable data structures easy to reach for and use, with escape hatches for more performant, mutable structures if need be; it's easier to reason about correctness when things are immutable by default. Correctness matters a lot for compilers. 3. Compilers are, in some sense, a bag of functions that iterate or map over trees. Pattern-matching is a way to reify trees: the branches of the trees become branches of your match expression. These languages support pattern-matching in a pervasive, first-class sort of way, as they prefer recursion and pattern matching over other kinds of control flow. 4. ML-likes have an advanced type system, while still being relatively ergonomic to write code in, as the type system admits some form of Hindley-Milner type inference. Good for correctness; but not strictly necessary for a compiler, maybe. 5. Lisp-likes don't generally have a type system (although some do!). But Lisps have extreme dynamism in the form of macros. Being able to tersely write code that expands out to exactly what you need can carry the day too. Whereas imperative languages sort of strike a compromise: their type systems are neither all that great (although C++, C#, and Java have all improved on type inferencing in the last decade) nor do they have anything as powerful as Lisp macros. 6. People and culture. Compiler people are generally made forged in academia, where it's generally taught in some Lisp or ML derivative. Type theory papers are usually written in some Haskell-like. Implementing a GHC extension is a path to a degree for grad student.