# How trustworthy and robust is GHC?

**URL:** <https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175>\
**Category:** Uncategorized\
**Created:** [May 30, 2026, 5:54pm UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175 "2026-05-30T17:54:41Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![ek2](https://avatars.discourse-cdn.com/v4/letter/e/7feea3/32.png) [@ek2](https://discourse.haskell.org/u/ek2)\
**Post date:** [May 30, 2026, 5:54pm UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175/1 "2026-05-30T17:54:41Z")

</div>

I compare GHC to LLVM. LLVM obviously has bugs (a lot of actually), but it’s used by nearly anyone, it’s bootstrappable, so it’s easy to back port fix, bootstrap from fixed version and check that new version is reproducible. LLVM has strong community, so releases are tested heavily before going public. GHC is the opposite one. GHC and Haskell have much smaller communities, GHC isn’t bootstrappable, so I even can’t imagine how they fix bugs and how they can be sure that recent compiler binary isn’t corrupted by 10 years old bug. For a long time there were no stable versions, so it’s common to see projects bounded to specific GHC version and packages versions, because managing all deps without LTS is impossible. And it looks like that GHC is still managed like an academia project a little bit, without strict checks before release, otherwise I can’t understand how issues like #26711 are possible.

---

<div class="post-metadata">

**Author:** ![ashokkimmel](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ashokkimmel/32/5111_2.png) [@ashokkimmel](https://discourse.haskell.org/u/ashokkimmel)\
**Post date:** [May 30, 2026, 6:30pm UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175/2 "2026-05-30T18:30:14Z")

</div>

GHC how do you say good test suite, which is why most bugs get caught. I would also say that most compiler bugs are of the form of a theoretically correct program getting rejected, rather than an incorrect result. In short, I think the testsuite and the wealth of hackage packages are the evidence for GHC being trustworthy.

---

<div class="post-metadata">

**Author:** ![bmobn00b](https://avatars.discourse-cdn.com/v4/letter/b/ecccb3/32.png) [@bmobn00b](https://discourse.haskell.org/u/bmobn00b)\
**Post date:** [May 30, 2026, 7:46pm UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175/3 "2026-05-30T19:46:45Z")

</div>

Please don’t compare LLVM with GHC, their underlying economics are on completely different scales.

---

<div class="post-metadata">

**Author:** ![prophet](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/prophet/32/5031_2.png) [@prophet](https://discourse.haskell.org/u/prophet)\
**Post date:** [May 30, 2026, 9:55pm UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175/4 "2026-05-30T21:55:36Z")

</div>

I think the comparison to LLVM is pretty interesting actually!  
LLVM receives much more funding and has many more active contributors than GHC. And yet issues like [#190540](https://github.com/llvm/llvm-project/pull/190540) still happen, where any program that used `musttail` or the `tailcc` calling convention with `byval` parameters (i.e. essentially any non-trivial program that used `musttail` or `tailcc`) was totally miscompiled under LLVM 22.1.  
This isn’t to say that there isn’t room for improvement in GHC’s processes (or LLVM’s), but I don’t think GHC is unique here in any way. Compilers are hard.

---

<div class="post-metadata">

**Author:** ![bmobn00b](https://avatars.discourse-cdn.com/v4/letter/b/ecccb3/32.png) [@bmobn00b](https://discourse.haskell.org/u/bmobn00b)\
**Post date:** [May 31, 2026, 6:11am UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175/5 "2026-05-31T06:11:22Z")

</div>

Yeah, that’s interesting if you’re familiar with both GHC and LLVM, but not necessarily if you’re familiar with neither.

---

<div class="post-metadata">

**Author:** ![HeinrichApfelmus](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/heinrichapfelmus/32/117_2.png) [@HeinrichApfelmus](https://discourse.haskell.org/u/HeinrichApfelmus)\
**Post date:** [May 31, 2026, 7:37am UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175/6 "2026-05-31T07:37:21Z")

</div>

Is “very” a trustworthy and robust answer?

I suppose that trustworthiness and robustness of software are currently very vague. Common proxies are:

- Number of automated tests.
- Amount of human scrutiny received (correlates with size of community, anticorrelates with size and complexity of the code).
- Severity of bugs that have been discovered (correlates with number of automated tests, anticorrelates with human scrutiny).

One issue with individual bugs is that testing can only show the presence of bugs, never their absence. Discovering severe bugs may be due to increased testing, not due to poorer code.

---

<div class="post-metadata">

**Author:** ![ek2](https://avatars.discourse-cdn.com/v4/letter/e/7feea3/32.png) [@ek2](https://discourse.haskell.org/u/ek2)\
**Post date:** [July 11, 2026, 7:24pm UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175/7 "2026-07-11T19:24:34Z")

</div>

Cardano is written in Haskell, has impressive market cap and I haven’t found info about disasters, bugs or anything like that in Cardano history. Big plus for GHC and Haskell, I guess.

---

<div class="post-metadata">

**Author:** ![janus](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/janus/32/1060_2.png) [@janus](https://discourse.haskell.org/u/janus)\
**Post date:** [July 12, 2026, 9:40pm UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175/8 "2026-07-12T21:40:27Z")

</div>

Cardano just had a chain split bug last year, see [Bitfinex writeup](https://blog.bitfinex.com/education/what-actually-happened-with-the-cardano-exploit/). I don’t think Bitcoin has had anything as bad since [the 2013 BerkeleyDB/LevelDB issue](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki). But this sample size is so small, I don’t know if you can reliably conclude anything regarding which programming languages prevent more bugs.

---

<div class="post-metadata">

**Author:** ![MangoIV](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mangoiv/32/3519_2.png) [@MangoIV](https://discourse.haskell.org/u/MangoIV)\
**Post date:** [July 13, 2026, 3:58pm UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175/9 "2026-07-13T15:58:26Z")

</div>

I was interested in what was the culprit here and looks like it was [input sanitization in low level user space code](https://github.com/IntersectMBO/cardano-base/commit/0dea04b893f2e3017050b5ff8036bdaff5580d32#diff-82fb2d0ea5a9f542856cc6571a87cddfc3392adba8dde410fa8e10a3324a2e94)… I don’t see how _a_ choice of language could prevent this.

---

<div class="post-metadata">

**Author:** ![simonmic](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/simonmic/32/1796_2.png) [@simonmic](https://discourse.haskell.org/u/simonmic)\
**Post date:** [July 13, 2026, 5:12pm UTC](https://discourse.haskell.org/t/how-trustworthy-and-robust-is-ghc/14175/10 "2026-07-13T17:12:56Z")

</div>

I agree with your general point. A little more context from an armchair observer: the bug was found in review and a patch was deployed the same day - but a discontented member of the review team deployed an exploit first. Despite this the blockchain kept running and quickly “self-healed”, minimising damage, as designed.

> The [Cardano](https://iohk.io/en/products) blockchain is one of the most visible and robust large-scale public applications built with Haskell. (100% [uptime](https://pooltool.io/networkhealth) since it went live in 2017.)  
> –me