Unfortunately there is still no way to actually bootstrap haskell (or anything based on it) which makes it impossible to put anything written in Haskell near any high trust linux distribution or environment.
I guess sandboxing the untrusted binary in a browser is -something- to let people play with haskell in a lower risk way for the moment at least but it is hard to take a language seriously or trust it with no way to bootstrap it from source.
You're speaking of "GHC haskell" there. Yes that is the main stream - and this will get solved there sooner or later - but you can also do a fair amount of Haskell without GHC. Eg MicroHs is getting increasingly capable and I believe is highly bootstrappable.
This is the same process used to port GHC to new architectures, like ARM. It is not easy to do, I don't know how many people can actually do it. But its possible and has been done multiple times.
Between old Hugs and the new MicroHs, I think it's definitely doable with some elbow grease. I just don't know if anyone in the community cares that much about bootstrapping tho.
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.
For someone like me that is less versed in these things, could you explain why bootstrapping a language is a required check for taking a language seriously? My criteria is far less stringent (is it stable? is it popular enough? is the toolchain mature? etc..), so I wonder what I am missing here.
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.
Unlike Nix and Guix, Stagex goes much further in that it has a 100% mandate on supply chain integrity. It trusts no single maintainer or computer and disallows any binary blobs. It is thus not possible to package any software that cannot be bootstrapped, reproduced, and signed by at least two maintainers.
Haskell and Ada are the only languages not possible for us to support, or any software built with them.
Everything else is just fine though.
I do hope both languages address this though, as it is blocking a lot of important open source software like pandoc or coreboot from being used in security critical environments.
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.
How is ghc compiled at all without bootstrapping? Or is there a magic binary in tree that is unreproducible? I have compiled ghc a few times and had no problems.
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.
The normalized lack of care about supply chain integrity is going pretty poorly, as any read of recent headlines indicates.
Stagex has a 100% full source bootstrapping, and reproducibility requirement that at least two maintainers must prove and sign for every package.
Stagex is also very heavily used and relied on in high value financial and scientific applications where trusting a binary some internet rando compiled is not even remotely acceptable.
Haskell and Ada are locked out of any high security applications until they are bootstrappable.
I was under the impression that most supply chain attacks target source code, not binaries, especially for large projects like OpenBSD.
Does StageX audit source code to the same extend that OpenBSD does? If not, then how would you compare the downgrade in security due to less code auditing vs the reassurance of reproducible builds?
Or, how would you compare StageX with Gentoo, in which the entire system is installed from source. Sure, you have to trust your initial installer, but how could I get a StageX system setup without first having access to a computer with some software installed? If we're at the point where we're worried that every Haskell program that has ever been compiled is owned, then I wonder why I should trust any software that might install StageX onto my computer, or the underlying hardware for that matter?
I'm not saying the status quo is good, but it is nontheless the status quo. Just about every machine on the cloud, mobile devices, etc all have non-source binaries somewhere, and besides some niche projects that actually have an assembly half-C compiler bootstrapping another tiny C compiler bootstrapping a real C compiler, this is not feasible for the vast software ecosystem as of today.
Most mainstream languages have a fairly straightforward bootstrapping process that doesn't rely on a trusted binary. And yes, most distrubutions ignore that, but nonetheless it is possible to use those languages in a high-sec environment if you put the work in.
I'm not sure that I agree that GHC can't be bootstrapped though. There is a process for porting to other architectures; its not an automated process and perhaps no one outside the GHC team can actually do it, but if for some insane reason NSA decided they want to use Haskell I'm not sure that they actually can't, if they put a lot of work in and hire GHC committers with high security clearances.
Stagex can already support all of those use cases provided they are not written in Haskell or Ada, and in fact Stagex is already used heavily in production. We bootstrap everything deterministically from 180 bytes of human auditable x86 machine code.
Rust, Go, Nodejs, we have you covered with complete full source bootstrapping and multi-party signed reproductions.
There is no good excuse for poor supply chain integrity anymore.
Yes, and that is a serious security problem because the only way to get trusted PCR values for TPM2 gated secure boot and full disk decryption applications, is with open source full source bootstrapped firmware.
Coreboot is the only option, but it has a hard requirement on Ada because that is what they wrote their intel graphics stack in.
Ada has had even less progress and I am not aware of any writeups.
TL;DR: Ada and Haskell need to have compilers implemented a language that has a full source bootstrap path such as C, Go, or Rust that implement just enough features to compile the official compilers.
Maybe that is literally why I asked the question, clearly I don't know as I have not spend the time investigating this problem that the commenter has. Asking some kind of gotcha question is not helpful.
Not anymore. Real pain in the ass to bootstrap but thanks to mrustc combined with our work in stagex we have an easy to audit path now in a 100% bootstrapped distro.
Unfortunately due to no first party support or interest from the Rust team, we have to build through 15+ versions to get to latest and it takes 6+ hours to build with a 20+ core system, but it works.
I remember running a Haskell interpreter on an HP Jornada running Jlime Linux. It was a long time ago in high school and I felt it was great because I thought it was a convenient way to do math classes since I could input some math formulas directly into the interpreter pretty much as they were. Definitely better than the Cassio scientific calculator my math teacher had us use.
It ran from a CF card so there was no chance it was as big as GHC. I can't seem to find the name of the interpreter.
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.
GHC (the Glasgow Haskell Compiler, after its original host university) is the de facto Haskell compiler and simultaneously the main research vehicle for the language and the neighbouring design space in general.
And frankly, while the compiler is awesome and so is the research, the constant churn and seeming inability to settle on what the good programming style and set of features actually is is what eventually turned me away from the language and to the more stable (if near-abandoned) pastures of Standard ML. (That was during the type families upheaval, so, about ten years ago? Don’t know how well it reflects the current state of the project.)
> 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.
> 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.
This is very impressive. I once built an educational Haskell programming + math. + art web site (mathvas.com). Something like this would have simplified that a lot.
I think WasmGC is very hard to make work with laziness.
A lazy value is always a closure on the heap.
If an expression might be unused, throw a closure which computes it on the heap
If the value is actually needed, invoke the closure. Optionally replace the closure with a black hole. A black hole is just a closure which pauses any thread which calls it, to be resumed once the first thread finishes with the expression
Once finished, replace with a closure which immediately returns the computation result. (Or often save the indirection because most concrete values also act as closures which immediately returns themselves using info table pointers trickery)
Anyway, iirc WasmGC wants very rigid types without dynamic type changes. Extra indirections could fix that, Oor maybe defunctionalizing thunks into a tagged union, but both sound expensive. Especially without being able to hook into the tracing step for indirection removal.
Also, Haskell supports finalizers so WasmGC would need that as well.
> 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.
WasmGC is still a 1.0, there are many kind of GC semantics that it cannot handle, for example it still doesn't cover all use cases needed for languages like C# and Go, e.g. interior pointers.
Can someone please help me understand the difference between features like this and the technologies like Blazor Wasm which actually let you write frontend in non js for websites?
Can anyone point to a "practical Haskell" tutorial/book/whatever for people that already know functional programming? I'm in this sour spot where most tutorials are boring to me so I just can't follow through.
I know what a monad is. What a typeclass is. Even what HKTs are. I can make sense of "a monad is just a monoid in the category of endofunctors" if I give it a few minutes to unravel the ball of twine... But I wouldn't be able to code a "ToDo list" in Haskell if my life depended on it.
But aside from resources, if you actually have something you want to build in Haskell, just go for it and struggle through --- that's the best way to learn that I've found
You might be better served talking to ChatGPT/Claude so it can tailor explanations based on your level of understanding. I've found that being super clear about concepts you understand well vs concepts you're unclear about makes for really effective explanations.
That is a really tough spot to be in. I don't know of any content that's aimed at someone like you.
You might be interested in reading the Monday Morning Haskell blog[0] series, which presents examples of how to do certain tasks in Haskell. See [1] for an example.
From Haskell I guess. Just not real world Haskell. I have never written more than a few hundred lines, but I've read a lot about its concepts in the abstract (and partially applied some insofar as other languages have let me.)
We cannot even include it in stagex because there is still literally no way to compile it from source and thus no way to do a real reproducible build, and there is no one left that cares about the language enough to do this.
Honestly it has to be regarded as a dead language until this is resolved.
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.)
I said it has to be treated as a dead language. I did not say it actually is one.
Being able to compile a compiler without binary blobs is a hard prerequisite to using that language for any application where security matters.
A language can have an active community and still be unsuitable for any real world use cases. Fortran is bootstrappable so I consider it more viable than haskell for real world use, even though it has far fewer fans (understandably).
Maybe it is more fair to call haskell an academic language or hobby language since it prioritized language design over basic supply chain security thus far.
If it becomes bootstrappable, then of course all the above critique is immediately retracted.
I cannot comprehend how you can get to the conclusion that a compiler that was litterally made so that people could hack into it and learn from that has no build documentation.
My project has no need of Haskell, but if anyone puts in the work to make haskell compileable from only public source code my team and I will put in the work to reproduce, package, and maintain it for the community for free as we do most other languages.
Your link details building GHC with an existing non reproducible GHC compiler binary compiled by a single individual that must be blindly trusted.
Full source bootstrapping means no binary blobs or trust in anyone else needed, which makes supply chain integrity possible. This is a bare minimum for any language to be considered for production use in any environment where security matters.
To me it -is- crazy when a major language compiler skips something so basic, but Haskell did.
To be fair rust team skipped this too, but thankfully rust is popular enough that a community member cared enough about high security applications to write mrustc, a bootstrap rust compiler written in C++. If not for that Rust would be in the same boat as Haskell.
Meanwhile Go and Zig did it right, and have both provided full source bootstrapping instructions from a C compiler since day 1.
I dug into this and it turns out there's an active, multi year effort underway to solve exactly this, along the exact ways you´d expect, with references to guix and bootstrappable.org etc, making steady progress: https://discourse.haskell.org/t/what-s-needed-to-bootstrap-g...
Reading through that thread gives me a very different idea of the state of haskell than I got from reading your comments.
Efforts pop up every once in a while, usually with no results. As I said elsewhere, if they actually pull it off this time then my tone changes to one of willingness from my team and I to put in the work to use these efforts to support deterministic multi-signed builds in stagex.
It would make GHC (and pandoc) something we could have in tree which would be awesome. I am just annoyed it seems like such a low priority.
Just you. Once the editor actually loads (turning the “Haskell source” pane on the left from the page background’s deep violet into a dark gray and displaying a “hello world” program), I can type perfectly fine. And I’m using a browser based on WebKitGTK, which is not exactly known for its stellar compatibility.
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.
Loading time is pretty rough, but it seems responsive enough after the initial load. Probably as fast or faster than downloading and installing GHC locally.
I would assume that in the near future one can preload, cache, update selected WASM packages. I also imagine that sooner than that we can preload open models in the browser to run the natively instead of only invoking third parties (e.g. window.ai in the DOM)
I think the immediate and obvious case would be educational materials. Other than that, technical achievements need not always be practical to be cool :)
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.
Pandoc is the first thing that comes to mind, but I also believe I have seen an uptick in software that I use being written in Haskell lately, though I can't remember what else off the top of my head.
Compilers are complicated. WASM has been a priority for the Haskell community for a while. Demonstrating GHC's ability to compile itself to WASM is thus a show that it is robust enough to compile a very complicated program into this backen.d
> jupyterlite-xeus builds jupyterlite, Jupyter xeus kernels, and the specified dependencies to WASM with packages from conda-forge or emscripten-forge.
Unfortunately there is still no way to actually bootstrap haskell (or anything based on it) which makes it impossible to put anything written in Haskell near any high trust linux distribution or environment.
I guess sandboxing the untrusted binary in a browser is -something- to let people play with haskell in a lower risk way for the moment at least but it is hard to take a language seriously or trust it with no way to bootstrap it from source.
You're speaking of "GHC haskell" there. Yes that is the main stream - and this will get solved there sooner or later - but you can also do a fair amount of Haskell without GHC. Eg MicroHs is getting increasingly capable and I believe is highly bootstrappable.
TIL MicroHS. Might try packaging this soon if it is in fact bootstrappable and can be deterministically compiled.
https://discourse.haskell.org/t/what-s-needed-to-bootstrap-g... people have worked replaying the history to bootstrap.
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...
This is the same process used to port GHC to new architectures, like ARM. It is not easy to do, I don't know how many people can actually do it. But its possible and has been done multiple times.
Between old Hugs and the new MicroHs, I think it's definitely doable with some elbow grease. I just don't know if anyone in the community cares that much about bootstrapping tho.
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.
So the problem is we want to use a different language to Haskell. GHC Haskell.
For someone like me that is less versed in these things, could you explain why bootstrapping a language is a required check for taking a language seriously? My criteria is far less stringent (is it stable? is it popular enough? is the toolchain mature? etc..), so I wonder what I am missing here.
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.
From 9.12, -fobject-determinism[1] will guarantee deterministic objects.
If it ever doesn't, do open a bug report[2]
[1] https://downloads.haskell.org/ghc/latest/docs/users_guide/us... [2] https://gitlab.haskell.org/ghc/ghc/-/issues
Good to know! Half the battle covered then.
Unlike Nix and Guix, Stagex goes much further in that it has a 100% mandate on supply chain integrity. It trusts no single maintainer or computer and disallows any binary blobs. It is thus not possible to package any software that cannot be bootstrapped, reproduced, and signed by at least two maintainers.
Haskell and Ada are the only languages not possible for us to support, or any software built with them.
Everything else is just fine though.
I do hope both languages address this though, as it is blocking a lot of important open source software like pandoc or coreboot from being used in security critical environments.
How are you bootstrapping a modern C compiler without an existing C/C++ compiler and linker?
From 180 bytes of human readable machine code all the way up.
https://codeberg.org/stagex/stagex/src/branch/main/packages/...
In assembly, like stage0 does: https://github.com/oriansj/stage0
Technically it is raw x86 machine code in hexadecimal, a scheme called "hex0"
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.
How is ghc compiled at all without bootstrapping? Or is there a magic binary in tree that is unreproducible? I have compiled ghc a few times and had no problems.
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.
Outside some fairly niche projects working on the problem, this is not a priority and most systems have straight binary dependencies.
The normalized lack of care about supply chain integrity is going pretty poorly, as any read of recent headlines indicates.
Stagex has a 100% full source bootstrapping, and reproducibility requirement that at least two maintainers must prove and sign for every package.
Stagex is also very heavily used and relied on in high value financial and scientific applications where trusting a binary some internet rando compiled is not even remotely acceptable.
Haskell and Ada are locked out of any high security applications until they are bootstrappable.
I was under the impression that most supply chain attacks target source code, not binaries, especially for large projects like OpenBSD.
Does StageX audit source code to the same extend that OpenBSD does? If not, then how would you compare the downgrade in security due to less code auditing vs the reassurance of reproducible builds?
Or, how would you compare StageX with Gentoo, in which the entire system is installed from source. Sure, you have to trust your initial installer, but how could I get a StageX system setup without first having access to a computer with some software installed? If we're at the point where we're worried that every Haskell program that has ever been compiled is owned, then I wonder why I should trust any software that might install StageX onto my computer, or the underlying hardware for that matter?
I'm not saying the status quo is good, but it is nontheless the status quo. Just about every machine on the cloud, mobile devices, etc all have non-source binaries somewhere, and besides some niche projects that actually have an assembly half-C compiler bootstrapping another tiny C compiler bootstrapping a real C compiler, this is not feasible for the vast software ecosystem as of today.
Most mainstream languages have a fairly straightforward bootstrapping process that doesn't rely on a trusted binary. And yes, most distrubutions ignore that, but nonetheless it is possible to use those languages in a high-sec environment if you put the work in.
I'm not sure that I agree that GHC can't be bootstrapped though. There is a process for porting to other architectures; its not an automated process and perhaps no one outside the GHC team can actually do it, but if for some insane reason NSA decided they want to use Haskell I'm not sure that they actually can't, if they put a lot of work in and hire GHC committers with high security clearances.
GHC absolutely could be bootstrapped, but someone versed in that ecosystem would have to put in a lot of work to do it.
If they ever do, my team and I will put in the work to package and maintain it in stagex.
Stagex can already support all of those use cases provided they are not written in Haskell or Ada, and in fact Stagex is already used heavily in production. We bootstrap everything deterministically from 180 bytes of human auditable x86 machine code.
Rust, Go, Nodejs, we have you covered with complete full source bootstrapping and multi-party signed reproductions.
There is no good excuse for poor supply chain integrity anymore.
Ada can't bootstrap? Ironic...
Yes, and that is a serious security problem because the only way to get trusted PCR values for TPM2 gated secure boot and full disk decryption applications, is with open source full source bootstrapped firmware.
Coreboot is the only option, but it has a hard requirement on Ada because that is what they wrote their intel graphics stack in.
It is a real mess.
Interesting, any link I could read to understand a bit more the situation?
Here is some background on the Haskell situation: https://www.joachim-breitner.de/blog/802-More_thoughts_on_a_...
Ada has had even less progress and I am not aware of any writeups.
TL;DR: Ada and Haskell need to have compilers implemented a language that has a full source bootstrap path such as C, Go, or Rust that implement just enough features to compile the official compilers.
Sounds like an opportunity to rebuild an ADA interpreter
Yes. Many efforts have started and fizzled out over the years before completion.
If you know anyone that takes this on and succeeds I have a 2k cash bounty for them, and we can likely find others.
I see, yes I most likely used a distro build ghc.
And where did you get the haskel compiler to do so?
You seem to be missing the point of bootstrapping
Maybe that is literally why I asked the question, clearly I don't know as I have not spend the time investigating this problem that the commenter has. Asking some kind of gotcha question is not helpful.
doesn't rust have the same problem? I've known this about haskell for ages and I think it's just the new norm ("trust us, bro")
Not anymore. Real pain in the ass to bootstrap but thanks to mrustc combined with our work in stagex we have an easy to audit path now in a 100% bootstrapped distro.
Unfortunately due to no first party support or interest from the Rust team, we have to build through 15+ versions to get to latest and it takes 6+ hours to build with a 20+ core system, but it works.
https://codeberg.org/stagex/stagex/src/branch/main/packages/...
nice, thanks
This is wild. I didn’t know this.
Neat... but with QEMU-WASM I'm wondering what actually does not run in the browser (obviously that doesn't required specific input).
Not a criticism, love everything that can provide hassle-free onboarding to learn a new language, just curious.
My hypothesis — worth testing — is that this will be significantly faster
Can the Haskell people help me refresh my memory?
I remember running a Haskell interpreter on an HP Jornada running Jlime Linux. It was a long time ago in high school and I felt it was great because I thought it was a convenient way to do math classes since I could input some math formulas directly into the interpreter pretty much as they were. Definitely better than the Cassio scientific calculator my math teacher had us use.
It ran from a CF card so there was no chance it was as big as GHC. I can't seem to find the name of the interpreter.
I'm guessing it was Hugs:
https://www.haskell.org/hugs/
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.
For those not well versed in Haskell, GHC is apparently this:
https://www.haskell.org/ghc/
What is GHC?
GHC is a state-of-the-art, open source compiler and interactive environment for the functional language Haskell.
GHC (the Glasgow Haskell Compiler, after its original host university) is the de facto Haskell compiler and simultaneously the main research vehicle for the language and the neighbouring design space in general.
And frankly, while the compiler is awesome and so is the research, the constant churn and seeming inability to settle on what the good programming style and set of features actually is is what eventually turned me away from the language and to the more stable (if near-abandoned) pastures of Standard ML. (That was during the type families upheaval, so, about ten years ago? Don’t know how well it reflects the current state of the project.)
> 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
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.
> 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.
You know... all these years, I thought GHC stood for GNU Haskell Compiler. Interesting to learn the actual name.
This is very impressive. I once built an educational Haskell programming + math. + art web site (mathvas.com). Something like this would have simplified that a lot.
Cannot paste into the editor (safari on iphone).
Does it use WasmGC, or bundle its own garbage collector?
I think WasmGC is very hard to make work with laziness. A lazy value is always a closure on the heap.
If an expression might be unused, throw a closure which computes it on the heap
If the value is actually needed, invoke the closure. Optionally replace the closure with a black hole. A black hole is just a closure which pauses any thread which calls it, to be resumed once the first thread finishes with the expression
Once finished, replace with a closure which immediately returns the computation result. (Or often save the indirection because most concrete values also act as closures which immediately returns themselves using info table pointers trickery)
Anyway, iirc WasmGC wants very rigid types without dynamic type changes. Extra indirections could fix that, Oor maybe defunctionalizing thunks into a tagged union, but both sound expensive. Especially without being able to hook into the tracing step for indirection removal.
Also, Haskell supports finalizers so WasmGC would need that as well.
> 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.
WasmGC is still a 1.0, there are many kind of GC semantics that it cannot handle, for example it still doesn't cover all use cases needed for languages like C# and Go, e.g. interior pointers.
Can someone please help me understand the difference between features like this and the technologies like Blazor Wasm which actually let you write frontend in non js for websites?
Yes we do.
https://github.com/haskell-miso
Can anyone point to a "practical Haskell" tutorial/book/whatever for people that already know functional programming? I'm in this sour spot where most tutorials are boring to me so I just can't follow through.
I know what a monad is. What a typeclass is. Even what HKTs are. I can make sense of "a monad is just a monoid in the category of endofunctors" if I give it a few minutes to unravel the ball of twine... But I wouldn't be able to code a "ToDo list" in Haskell if my life depended on it.
Pls help.
Seconding Haskell in Depth.
But aside from resources, if you actually have something you want to build in Haskell, just go for it and struggle through --- that's the best way to learn that I've found
I always liked https://www.extrema.is/articles/haskell-books/haskell-tutori... . But there's a lot out there. Have a look at https://joyful.com/Haskell+map . Or: read code. Or, just build practical stuff and seek help in the chats/fora when you hit problems.
I typically recommend LYAH (https://learnyouahaskell.github.io/chapters.html), followed by Real World Haskell (already mentioned).
You might be better served talking to ChatGPT/Claude so it can tailor explanations based on your level of understanding. I've found that being super clear about concepts you understand well vs concepts you're unclear about makes for really effective explanations.
That is a really tough spot to be in. I don't know of any content that's aimed at someone like you.
You might be interested in reading the Monday Morning Haskell blog[0] series, which presents examples of how to do certain tasks in Haskell. See [1] for an example.
[0]: https://mmhaskell.com/blog
[1]: https://mmhaskell.com/blog/2025/5/19/comparing-code-leetcode...
Build a snake game in stages: https://github.com/lsmor/snake-fury
Build a small web-app: https://jaspervdj.be/posts/2017-12-07-getting-things-done-in... (the video link is down, but exists somewhere on youtube.)
https://www.manning.com/books/haskell-in-depth is meant for you!
Also https://learn-haskell.blog/
Have you tried Real World Haskell?
No, but the table of contents looks promising, thanks!
See also What I Wish I Knew When Learning Haskell: https://sdiehl.github.io/wiwinwlh/
It's more up to date.
Haskell school of music
Where does your functional programming experience come from? That could help in finding a suitable resource.
From Haskell I guess. Just not real world Haskell. I have never written more than a few hundred lines, but I've read a lot about its concepts in the abstract (and partially applied some insofar as other languages have let me.)
Actual title: "GHC now runs in your browser"
Serious question. Is Haskell still a thing?
https://emanote.srid.ca is written in Haskell.
(I'm the author)
Pandoc is an extremely popular Haskell tool.
https://mercury.com
Yes, it's still a thing.
We cannot even include it in stagex because there is still literally no way to compile it from source and thus no way to do a real reproducible build, and there is no one left that cares about the language enough to do this.
Honestly it has to be regarded as a dead language until this is resolved.
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.)
I said it has to be treated as a dead language. I did not say it actually is one.
Being able to compile a compiler without binary blobs is a hard prerequisite to using that language for any application where security matters.
A language can have an active community and still be unsuitable for any real world use cases. Fortran is bootstrappable so I consider it more viable than haskell for real world use, even though it has far fewer fans (understandably).
Maybe it is more fair to call haskell an academic language or hobby language since it prioritized language design over basic supply chain security thus far.
If it becomes bootstrappable, then of course all the above critique is immediately retracted.
> If it becomes bootstrappable, then of course all the above critique is immediately retracted.
So basically you're saying you're just trying to get people to carry water for your project?
> because there is still literally no way to compile it from source
https://gitlab.haskell.org/ghc/ghc/-/wikis/building/#buildin...
I cannot comprehend how you can get to the conclusion that a compiler that was litterally made so that people could hack into it and learn from that has no build documentation.
My project has no need of Haskell, but if anyone puts in the work to make haskell compileable from only public source code my team and I will put in the work to reproduce, package, and maintain it for the community for free as we do most other languages.
Your link details building GHC with an existing non reproducible GHC compiler binary compiled by a single individual that must be blindly trusted.
Full source bootstrapping means no binary blobs or trust in anyone else needed, which makes supply chain integrity possible. This is a bare minimum for any language to be considered for production use in any environment where security matters.
To me it -is- crazy when a major language compiler skips something so basic, but Haskell did.
To be fair rust team skipped this too, but thankfully rust is popular enough that a community member cared enough about high security applications to write mrustc, a bootstrap rust compiler written in C++. If not for that Rust would be in the same boat as Haskell.
Meanwhile Go and Zig did it right, and have both provided full source bootstrapping instructions from a C compiler since day 1.
> Your link details building GHC with an existing non reproducible GHC compiler binary compiled by a single individual that must be blindly trusted.
You mean Hadrian? Its source is shipped with GHC.
Even if you were not to trust Hadrian, the doc also has info about building GHC using make.
> since day 1.
Could it be that languages made around 2010 have learned a thing or two from previous languages?
Building GHC regardless of using hadrian or make still requires an existing GHC binary. That is the core trust problem.
GHC has a recursive dependency on itself with no way to go back before that loop.
Interested in why you consider Zig's precompiled WASM blob full source bootstrapping, is it because it's shipped by first party?
I did not package Zig myself. Does that blob make it into final artifacts? If so that is a bug we should swiftly correct.
I dug into this and it turns out there's an active, multi year effort underway to solve exactly this, along the exact ways you´d expect, with references to guix and bootstrappable.org etc, making steady progress: https://discourse.haskell.org/t/what-s-needed-to-bootstrap-g...
Reading through that thread gives me a very different idea of the state of haskell than I got from reading your comments.
Efforts pop up every once in a while, usually with no results. As I said elsewhere, if they actually pull it off this time then my tone changes to one of willingness from my team and I to put in the work to use these efforts to support deterministic multi-signed builds in stagex.
It would make GHC (and pandoc) something we could have in tree which would be awesome. I am just annoyed it seems like such a low priority.
This entire thread, including your original comment, isn’t really about your efforts though. It was about Haskell.
As I said : I read your comments, formed an idea based on that, dug deeper to see for myself, and got a completely different picture.
Whether that is because of how you write or because of how I read I’ll leave for you to decide.
Is it just me or is it actually impossible to type anything?
Just you. Once the editor actually loads (turning the “Haskell source” pane on the left from the page background’s deep violet into a dark gray and displaying a “hello world” program), I can type perfectly fine. And I’m using a browser based on WebKitGTK, which is not exactly known for its stellar compatibility.
Thanks, I have given up waiting it appears to take minutes on a phone.
Hm, works fine here (Firefox on Ubuntu).
But getLine doesn't seem to be implemented, so there is output but not yet input :)
I thought you were talking about typing in Haskell at first lol.
They were! Typing...in Haskell...on a keyboard...on their screen...
Interesting technical achievement but what would this be used for in practical terms?
I will give a lecture about Haskell next week and might use this website for demonstration.
For one, it demonstrates how far the ghc wasm backend has come, in that such a large system as ghc itself can now run in wasm
yeah why would anyone want 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.
It can target wasm, the point of the post is that it’s now mature enough to be able to build itself for wasm and run in a browser.
This is a show case of the wasm backend
GHC is built with GHC lol
Loading 50mb of WASM is a big tradeoff just to run code on a website.
For comparison: the homepage of cnn.com right now is 33.37MB on my machine. 16.82MB of which is JavaScript.
Loading time is pretty rough, but it seems responsive enough after the initial load. Probably as fast or faster than downloading and installing GHC locally.
I would assume that in the near future one can preload, cache, update selected WASM packages. I also imagine that sooner than that we can preload open models in the browser to run the natively instead of only invoking third parties (e.g. window.ai in the DOM)
I think the immediate and obvious case would be educational materials. Other than that, technical achievements need not always be practical to be cool :)
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
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.
We are? Please share.
I don't have the same impression, but https://github.com/PostgREST/postgrest and https://github.com/koalaman/shellcheck are some popular ones that may be useful to hn'ers.
And https://github.com/mchav/dataframe?tab=readme-ov-file#datafr... is a library/framework that has had quite some velocity lately
https://joyful.com/Haskell#What+are+some+Haskell+apps
Pandoc is the first thing that comes to mind, but I also believe I have seen an uptick in software that I use being written in Haskell lately, though I can't remember what else off the top of my head.
https://mercury.com
In addition to the other responses, it's also worth noting that wasm itself is useful outside of the web itself; e.g. in containerized applications.
Compilers are complicated. WASM has been a priority for the Haskell community for a while. Demonstrating GHC's ability to compile itself to WASM is thus a show that it is robust enough to compile a very complicated program into this backen.d
Have you ever used Godbolt? The Rust playground? The Typescript's playground? The Go playground?
It lets you have that without the pain of hosting compilers server side.
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?
Teaching