Just as PureScript has expanded into the backend after having long been assigned to the frontend (in people's minds), it is now spreading to all areas of programming. It’s a polymorphic language that can target Erlang for concurrency, Chez Scheme for raw speed, etc. Here is why it works.
A few months ago, I wrote an article about how PureScript serves as a "quiet rewrite of the Web", allowing developers to build robust, mathematically sound applications on the rooftops of JavaScript’s chaotic empire.
But as I delved deeper into the ecosystem, a profound realization hit me: I could have written the exact same article by replacing the word "JavaScript" with "Erlang", or "C++", or "Chez Scheme", etc. Not all languages: some aren't dense or powerful enough, others are currently being explored (e.g. WASM). But quite a few! In fact, often the ones having a very, very interesting runtime. JavaScript is a special case, as it is notoriously more controversial. But the principle is the same.
In fact, and with a slightly broader definition, PureScript does not only support powerful polymorphism in its type system. The language itself is polymorphic.
Let's pause for a second. What exactly is polymorphism in programming?
At its core, and to simplify things a bit, polymorphism allows a single piece of code to adapt its behavior depending on the data it receives. Take a simple polymorphic function:
-- Type "a" is generic.
-- In real code, we'd add the constraint "Show a =>"
display :: forall a. a -> String
display value = "Data: " <> show value
display 42 -- Int context.
-- Returns 'Data: 42'
-- as if the signature was:
-- process :: Int -> String
display "Hello" -- String context.
-- Returns 'Data: "Hello"'
-- as if the signature was:
-- process :: String -> String
The function doesn't exist as a single, rigid block of code. Instead, the function will take the right shape at the very moment you call it: either the shape for integers, or the shape for strings. It is the context that defines what the function actually is.
It's the exact same thing for PureScript itself, as a whole. Its nature can change depending on your context of use.
It turns out that PureScript is quietly solving the holy grail of software engineering, the "Write Once, Run Anywhere" promise, by succeeding exactly where older cross-platform languages (like Haxe) hit a glass ceiling. Not just inside the code, in some parts, but with the code itself.
Here is how, and more importantly, why.
Choose your morph (without changing your logic)
If you think PureScript is just "Haskell for the browser", you may be missing one of the biggest paradigm shifts of the decade. Besides its unique features (e.g. Row polymorphism), and thanks to its unique architecture, PureScript compiles your code into an intermediate, mathematically pure abstract syntax tree called CoreFn. This tree can be transpiled into (almost) anything which is sufficiently powerful to understand it, and translate it in its own terms. That's philosophically close to WASM, even though it deals with a completely different topic: you define a universal layer, to facilitate the translation work everywhere else.
From there, the community has built alternative backends that allow you to deploy your identical business logic to radically different physical realities:
- You want top-tier web UI and Node.js efficiency? Keep the default compiler or use purs-backend-es for highly-optimized ECMAScript.
- You want massive telecom-grade concurrency and 99.99999% uptime? Transpile to the BEAM (Erlang VM) using purerl. You get the legendary resilience of Elixir/Erlang actors, but with absolute compile-time type safety.
- You want raw, bare-metal computing speed for heavy algorithms? Transpile to Scheme using purescm, which leverages the formidable Chez Scheme compiler to come very close to C/C++/Rust-level performance on recursive and computational tasks (thanks to 30 years of research by Cisco).
Your core domain (your algorithms, parsers, state machines, and business rules) does not change by a single comma. Yes: not, a, single, comma.
Of course, your target language can and should influence what PureScript will offer to be transpiled into it. And the level of abstraction and generality given by PureScript is directly the one of Category Theory: you will almost certainly find the right tool for each problem. That's a permanently bidirectional dialogue between the two sides, maintained by great developers from the community.
The Haxe paradox: Why did it stall?
This "compile to anything" promise sounds familiar. In the 2000s and 2010s, languages like Haxe tried to be the ultimate Swiss Army knife, compiling to C++, Java, PHP, and JS. While Haxe became a massive success in the indie gaming industry (shoutout to Dead Cells), it never conquered the mainstream backend or frontend world.
Why? Because of the Lowest Common Denominator Syndrome.
Haxe is an Object-Oriented, imperative language. It tried to abstract the world by forcing its own Standard Library onto every target. When you compiled Haxe to C++, you didn't get idiomatic, lightning-fast C++: you got C++ weighed down by a Haxe garbage collector. When you compiled to JS, you got a heavy runtime overhead. You lost the native superpowers of the target platform.
Furthermore, from a paradigm perspective, Haxe offered nothing that Java, C#, or TypeScript didn't already have. Why use a cross-platform layer when native tools do OOP better?
Haxe felt counterproductive for some. It may have suffered from Esperanto syndrome. A universal system must include its parts without replacing them (not blindly, at least), so that it can grow alongside them.
The PureScript epistemology: purity as a boundary
PureScript succeeds where Haxe stalled because it adopts a radically different philosophy: Symbiosis through Purity.
PureScript does not try to replace the native ecosystem. It fully respects it. And it grows with it.
Because PureScript is strictly mathematically pure, its compiler doesn't need to inject a heavy "PureScript Virtual Machine" into the target code.
- Zero-Cost Abstraction: PureScript Arrays compile to native JS Arrays. PureScript Strings are native Strings. The integration is seamless.
- The FFI Philosophy: PureScript knows it cannot do database I/O or DOM manipulation natively. Instead of faking a universal HTTP library that runs poorly everywhere, the culture encourages you to use platform-specific Foreign Function Interfaces (FFI).
You write your business logic once, in 100% pure code. Then, you plug in the right FFI. And don't worry about rewriting the world from scratch: the core kernels and standard bindings have already been written by the community for each runtime! And for libs: if you target Node.js, you plug in purescript-node-postgres, if you target Erlang, you plug in purescript-erl-epgsql.
Conclusion: the ultimate alchemy
The dilemma of hybrid technologies is the risk of creating a gray mush, a tool that loses the qualities of both its parents. In software engineering, attempting to support everything often results in a mediocre middle ground: a language that is not as fast as C, as expressive and safe as Haskell, etc.
Don't worry. In this case, the spoon is shaped like mud, but it's just that PureScript might play a prank on you! 😉
In reality, being in the middle should not necessarily imply losing quality. PureScript completely avoids this gray mush by refusing to mix the substances until the very last second. It takes the absolute mathematical rigor of Haskell (substance A) and respectfully marries it to the omnipresence of V8, the resilience of BEAM, or the speed of Scheme (substance B). The substances remain as they are, they just work together so closely that one can still speak of hybridization.
No matter what the people who encounter your product prioritize (speed, safety, concurrency...), you can now rest easy and know your language inside and out.
Needless to say, no single runtime is perfect for everything. In practice, PureScript acts as the unified, overarching language for your entire project, but your transpilation targets can differ from one folder to another. That is the whole point: every pillar of your architecture gets its own privileged runtime. For instance, your background workers and core algorithms can be transpiled to Chez Scheme for raw, bare-metal speed; your real-time WebSocket brokers can compile to Erlang's BEAM for flawless, distributed concurrency; and your user-facing API can run on highly-optimized Node.js.
It is not a downward compromise. PureScript is an epistemological little friend that protects your code, your thinking, from the chaos of the outside world, while letting you choose the exact engine you want to power it. It's made for that. It isn't afraid of movement. It encourages you to use the best runtime for your goal, without having to learn yet another language, right now.
The quiet rewrite of the web is expanding, but it does not stop at the browser window. It is coming for distributed systems, heavy data pipelines, and bare-metal computations. By allowing developers to decouple their business domain from the physical execution engine, PureScript is silently shifting the power dynamics of software architecture.
We no longer have to compromise between safety and performance. We just have to choose the right form for the right environment.
It’s a long-term endeavor, underway on all fronts: academic and theoretical, as well as practical and industrial. But it’s an endeavor in which the progress made has now become so significant that it allows us to (re)discover the joy of doing this craft.
Say Hello to your little polymorph, say Hello to PureScript.
P.S. Oh, and I almost forgot: a little concrete code never hurts! If you want to see what a production-ready PureScript project looks like in practice, check out this example repository, when our little polymorphic friend wants to take the form of Node:
👉 PureScript fullstack example (Node runtime)
Also find a fibo multi-runtime benchmark here:
