When you combine the absolute safety and elegance of a purely functional language with the raw execution speed of a modern low-level language, it's like discovering that space and time are inextricably linked: a whole new dimension opens up to you.
In my previous article, I introduced , a compiler backend that brings the absolute mathematical safety of PureScript to the 70% of the web that still runs on PHP.
The goal was to prove that we do not have to sacrifice modern safety and ergonomics just because we target a runtime that is, at first glance, not the most natural.
Today, we are looking at the exact opposite end of the spectrum.
If PHP was about ultimate portability and legacy compatibility, what happens when we want pure, raw metal speed?
What happens when we want true multi-core concurrency, static native binaries, and a garbage collector designed for extreme high-throughput?
Say hello to one of my recent projects: gopurs, a super-optimized PureScript-to-Go compiler.
And let me spoil the end of the story right away: by combining the high-level semantic purity of PureScript with the raw execution force of modern Go, the final compiled code matches Chez Scheme on pure computational benchmarks.
Yes, Chez Scheme, one of the absolute historical champions of functional AOT compilation (i.e., decades of compiler optimizations).
This will be a shorter article in the series, but here is a quick version of the story...
Breaking the AOT ceiling: how TAST changed everything Historically, compiling dynamic or highly polymorphic functional languages (like PureScript or Haskell) to statically typed languages like Go has always been a nightmare.
Older attempts often relied on mapping everything to Go's (or ).
It works, but it's a performance sacrifice.
Every primitive value you assign to an is boxed and escapes to the heap, generating massive pressure on Go's Garbage Collector.
To solve this, initially used a flat struct (a tagged union, inspired by V8), keeping things mostly on the stack.
It was much faster, but it wasn't enough.
The real bottleneck was the lack of structural type information: PureScript's standard AST erases types.
This is where the Typed Abstract Syntax Tree (TAST) comes in.
By relying on a custom fork of the PureScript compiler and the brilliant (than you can find here), preserves deep type information all the way down to the code generation phase.
This allows the compiler to perform strict monomorphization, for example.
Zero boxing on the hot paths.
Zero overhead.
The abstractions literally melt away at compile time, leaving only blazing-fast imperative loops that the Go compiler can aggressively optimize.
Fearless Concurrency: meets Goroutines 🚥 One of the greatest strengths of PureScript is its monad: a powerful, composable way to handle asynchronous effects.
In the JavaScript world, is carefully mapped to the single-threaded Event Loop.
But Go doesn't have a single-threaded Event Loop.
Go has goroutines and true, shared-memory parallelism across multiple OS threads.
Instead of trying to fake a JS-like event loop, maps and directly to native goroutines.
This means that when you write standard, pure PureScript asynchronous code, you are implicitly getting true multi-core execution for free.
I benchmarked this on a heavily CPU-bound workload (running 10 parallel Fibonacci computations).
In JS (V8), the event loop gets blocked, and the 10 tasks execute sequentially in roughly ~15,000 ms.
In Go (), the 10 tasks are automatically distributed across the 10 CPU cores of the machine, finishing in ~1,250 ms.
It is roughly 12x faster for the exact same PureScript code.
It's the absolute dream of developer experience, isn't it?
You write pure, mathematically proven abstractions, and the backend orchestrates the parallelization on the hardware level.
You don't have to care about low-level machinery, too often.
FFI without the pain: the WebAssembly parser A language is only as good as its ecosystem, and cross-compilation of