By ByteBot
Edward Kmett shipped a JIT compiler for Haskell that runs on the JVM — and he built it in about a week. The project, called Turbo Haskell Compiler (THC), already compiles pandoc, Haskell’s own parser and lexer generators, and GHC itself. Haskell has had JVM ambitions before. None of them came with GraalVM JIT warmup, full GHC 9.14.1 prim-op coverage, and zero-copy interop with Python, R, and JavaScript.
How THC Splits the Work With GHC
THC doesn’t replace GHC — it extends it. GHC still does the hard parts: parsing, typechecking, desugaring all that Haskell surface syntax, and running its optimization passes on Core. Core is GHC’s compact intermediate representation, a typed lambda calculus that every Haskell program collapses into before the compiler touches machine code.
After Core optimization, where GHC would normally hand off to its STG machine or LLVM backend, THC intercepts. It takes the optimized Core and feeds it to GraalVM’s Truffle framework, which interprets the AST, profiles hot paths, and JIT-compiles them into native machine code. The architecture is clean: you write standard Haskell, GHC validates it, THC runs it on the JVM.
The Practical Angle: Zero-Copy Polyglot FFI
JIT warmup is nice. The genuinely interesting part is polyglot interop.
THC provides zero-copy FFI to Python, Ruby, R, and JavaScript. Haskell’s Data.Text converts directly to Truffle’s TruffleString without copying. From Haskell, you can call into Python data science libraries, R statistical packages, or JavaScript — without marshaling overhead and without writing C bindings.
Kmett was deliberate about this. He explicitly avoided direct Java FFI, explaining in the Hacker News discussion that direct Java interop “has never had a satisfying answer for any language that isn’t Java.” Truffle’s polyglot API sidesteps the problem entirely. The practical result: a Haskell function can call a pandas DataFrame operation with the same ease as calling another Haskell module.
JVM Capabilities Haskell Didn’t Have Before
Running on the JVM unlocks three things that native GHC doesn’t offer:
- Project Loom green threading: THC supports lightweight MVar semantics built on Java’s virtual threads. You get millions of concurrent lightweight threads without the callback-heavy async patterns typical of high-throughput servers.
- SIMD via the JVM Vector API: THC uses the JVM’s incubating Vector API with runtime species selection, meaning SIMD operations adapt to whatever hardware is available at runtime.
- Ahead-of-time compilation: Via GraalVM Native Image, THC can produce standalone executables — binaries that start in milliseconds without a JVM at runtime.
Performance: Honest Numbers
The range right now is wide: 3x faster to 3x slower than native GHC, depending on the workload. After JIT warmup, the typical result is 10–20% slower than native GHC. For CPU-bound, hot-loop code, native GHC still wins. Compile times are rough — Kmett acknowledged this directly in the HN thread.
This is not a GHC replacement. For performance-critical numerical code or systems work, native GHC or the LLVM backend is the better choice. THC’s value proposition is different: polyglot interop, JVM ecosystem access, and green threading for I/O-heavy workloads.
Try It
THC is open source on GitHub. You need:
- GHC 9.14.1 (including
ghc-pkgandrunghc) - cabal-install 3.16
- GraalVM 25.3.4.1 / JDK 25
- Python 3.12+
The requirements list is a fair reflection of where the project sits: ambitious, functional, and not yet streamlined for casual adoption. Kmett also mentioned an in-development editor project, thc-edit, which may reduce the setup friction when it ships.
The Bigger Picture
GraalVM 25.x is mature in 2026. TruffleRuby, GraalPy, FastR, and GraalJS have demonstrated that the JVM can host production-grade implementations of dynamic languages. THC extends that to a statically typed functional language — and does it with full prim-op compatibility with the production compiler.
The more interesting question THC raises isn’t “should Haskell developers switch?” Most won’t. It’s whether the GraalVM polyglot runtime, with its zero-copy cross-language calls, makes Haskell accessible to developers who’ve always wanted the type safety but couldn’t stomach the FFI story. Kmett’s announcement post is worth reading in full — it’s the kind of project writeup that makes you understand why he’s been a fixture in Haskell for two decades.
