hx vs Cabal and Stack
Cabal and Stack are the established Haskell build tools. hx is a single fast binary that wraps and replaces both — without asking you to leave your existing projects behind.
The short version
hx is a native Rust binary that does what Cabal and Stack do — build, test, run, format, lint, publish — from one command, with managed toolchains and deterministic lockfiles. It reads your existing .cabal files and resolves from Hackage, so adopting it does not mean rewriting anything.
If you want the honest one-liner: hx is to the Haskell toolchain what cargo is to Rust. One tool, fast, predictable.
Speed
Every number below is hx 0.9.2 against cabal 3.12.1.0 on the same machine (Apple M4, GHC 9.8.2) and the same project, a three-module executable depending only on base, measured with hyperfine on 2026-09-10. hx is a native binary with no GHC runtime to start, which is most of the difference.
| Operation | hx | Cabal | Speedup |
|---|---|---|---|
| CLI startup | 3.2 ms | 18.9 ms | 6.0× |
| Cold build | 0.52 s | 2.89 s | 5.6× |
| Incremental (no changes) | 3.7 ms | 17.7 ms | 4.8× |
| Clean | 5.2 ms | 18.5 ms | 3.6× |
Dependency resolution is a separate cost, last measured at 0.8.0. A warm hx lock reads a cached, pre-parsed Hackage index in about 37 ms. The first lock after the index changes parses the full index once, in about 4.9 s, and the result is cached for 24 hours.
Stack was not re-measured for this release, so it is left out of the table rather than carried over from older runs. The same goes for project init. The figures this page used to show (a 0.39 s cabal incremental, a 180 ms cabal clean, 22× on clean) came from an earlier run that was never reproduced and overstated the gap; the numbers above are the measured ones. Methodology, the reproduction script and the per-version history are on the benchmarks page.
The gap is widest where it is felt most: the dozens of small commands you run all day.
Workflow
| hx | Cabal | Stack | |
|---|---|---|---|
| Build / test / run / format / lint / publish | One tool | Cabal + external tools | Stack + external tools |
| Managed compiler toolchains | GHC and BHC | via ghcup | curated resolvers |
| Lockfiles | Deterministic TOML, checksum-verified | cabal.project.freeze | stack.yaml.lock |
Reads existing .cabal files | Yes | Yes | Yes |
| Distribution | Single static binary | Haskell binary | Haskell binary |
| Plugins | Steel (Scheme) plugin system | — | — |
Will it work with my project?
Yes. hx reads .cabal files directly and resolves dependencies from Hackage, and it can import existing Cabal or Stack projects. You can adopt it incrementally — use hx build where it helps and keep everything else as it is. Nothing about your package, your dependencies, or your code has to change.
When to use which
Use hx if you want one fast tool for the whole workflow, deterministic builds, managed GHC/BHC toolchains, and instant commands.
Stick with Cabal or Stack if you depend on a workflow detail hx does not cover yet, or your team’s tooling is deeply wired into one of them — and revisit hx as it matures. hx is compatible either way, so there is no lock-in to trying it.
Get started with hx → · Full benchmarks → · Why we built it in Rust →