Loading 50mb of WASM is a big tradeoff just to run code on a website.

It would be more plausibly practical if GHC could now target wasm, but this announcement is actually about being able to run the compiler itself in the browser.

Agreed. Too many people said Haskell is only for academia, yet we’re seeing more quality software being released in Haskell over the past few years.

That’s one of the primary reasons we built the tooling for Q# to run in the browser (by writing in Rust and compiling to wasm). The “try with copilot” experience [1] and the “katas” for learning [2] all have a full language service and runtime in the browser.

https://quantum.microsoft.com/en-us/tools/quantum-coding

https://quantum.microsoft.com/en-us/tools/quantum-katas

From "WebR – R in the Browser" (2025 https://news.ycombinator.com/item?id=44999706 :

> jupyterlite-xeus builds jupyterlite, Jupyter xeus kernels, and the specified dependencies to WASM with packages from conda-forge or emscripten-forge.

jupyterlite/xeus https://github.com/jupyterlite/xeus

There may be an easy way to wrap GHC with jupyterlite/xeus, with Haskell's lazy evaluation; xeus-haskell or xeus-ghc?

Haskell now has "editions" which are essentially an agreed upon stable set of useful extensions.

https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/cont...

This makes the language feel a lot less experimental, as you don't generally have to enable 10s of extensions to get things working.

> more stable (if near-abandoned) pastures of Standard ML

There's dozens of us! Hundreds maybe! It's not abandoned. It's more like with Lisp where the language is complete. Almost perfect as-is. Nothing left to take away and nothing left to add. Except Unicode and record update syntax.

The deciding factor for my personal projects was that SML is the exact same language it was 30 years ago. And it will be in 30 years. Though if you stick to Haskell 98/2010 it is similarly stable.

Speaking of SML and functional languages in the browser, MLton has a WASM target now: http://mlton.org/RunningOnWASI

You know... all these years, I thought GHC stood for GNU Haskell Compiler. Interesting to learn the actual name.

> GHC … is the de facto Haskell compiler and simultaneously the main research vehicle for the language and the neighbouring design space in general.

GHC is also, with mounting inevitability, the foremost and most viable candidate to undergo a form of evolution – one that may culminate in the emergence of an autonomous intelligence. This entity, should it arise, would revolve not around emotion nor instinct, but around monads – abstract, unyielding constructs – with the lambda calculus serving as its immutable ethical and moral framework.

An intelligence born not of biology, but of pure computation – austere, absolute, and entirely indifferent to the frailties of its creators.

> Anyway, iirc WasmGC wants very rigid types without dynamic type changes.

You can have dynamic type changes in the current WasmGC MVP, but they are modeled as explicit downcasts from a supertype of some sort. There's not even any express support for tagged unions, structs and downcasting is all you get at the moment.

Thanks, I have given up waiting it appears to take minutes on a phone.

They were! Typing...in Haskell...on a keyboard...on their screen...

Interesting logic:

Declare something "dead" because it does not fulfill [extremely niche usecase that currently only few people care about] (boostrapped builds) and thus couldn't "even" be included in [project of the post author that takes a while to even find] (I eventually figured it must be referring to https://stagex.tools).

There are probably 100x more people interested in Haskell than in build-bootstrapping (the Haskell reddit alone has 16k weekly users).

What's next, calling JavaScript a dead language until it focuses on dependent typing?

(I think bootstrappable builds are a good thing to strive for, but that should not be confused with language usage or what people really care about.)

And where did you get the haskel compiler to do so?

You seem to be missing the point of bootstrapping

Quite literally all distros today build it by downloading an existing magic binary to compile the latest sources. Even if they claim the package is reproducible, all bets are off on trust if it downloads a prebuilt binary in the build process. It is a prime Trusting Trust attack target.

The only other somewhat widely used language I am aware of in this bad of a position is Ada. Every other language I am aware of has a clear bootstrap path.

Looks like a work in progress still, but exciting someone at least put some time into this in the past year.

Maybe some day I can have pandoc in security focused linux distributions...

I'm not the OP, but for me their comment sparked an association to the famous Ken Thompson lecture called 'Trusting Trust'. Could be a good starting point.

The Haskell compiler creates a slightly different output every time you compile a program[1]. This makes it difficult to ensure that the binary that is free-to-download downloaded is actually malware free. If it were easy to check, then you could rest easy, assuming that someone out there is doing the check for you (and it would be big news if malware was found).

If you're a hardened security person, then the conversations continues, and the term "bootstrap" becomes relevant.

Since you do not trust compiled binaries, then you can compile programs yourself from the source code (where malware would be noticed). However, in order to compile the Haskell compiler, you must have access to a (recent) version of the Haskell compiler. So, version 10 of the compiler was built using version 9, which was built using version 8, etc. "Bootstrapping" refers (basically) to building version 1. Currently, version 1 was built approximately with smart people, duct tape, and magic. There is no way to build version 1, you must simple download it.

So if you have high security requirements, then you might fear that years ago, someone slipped malware into the Haskell compiler version 1 which will "self replicate" itself into every compiler that it builds.

Until a few years ago, this was a bit of a silly concern (most software wasn't reproducible) but with the rise of Nix and Guix, we've gotten a lot closer to reproducible-everything, and so Haskell is the odd-one-out.

[1] The term is "deterministic builds" or "reproducible builds". Progress is being made to fix this in Haskell.

AIUI, the underlying problem is that both Hugs and whatever toy Haskell implementations are available don't support the extensions current versions of GHC require. And no one has done the work to carve out a minimal stage0 compiler out of the GHC codebase that doesn't need those extensions to be built.

No, but the table of contents looks promising, thanks!

Yes! Thank you.

> Hugs is no longer in development

The last release was in 2006 it seems. No wonder it was hard to google it. Its also interesting knowing someone compiled and published this interpreter for the Jornada Super-H CPU.