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, 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. It can take on completely different forms depending on the context.
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.
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 rival 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.
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.
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.
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. If, in this case, the spoon is shaped like mud, 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 as long as there is no need to mix them (i.e., at runtime). No matter what the people who encounter your product prioritize, you can now rest easy and know your language inside and out.
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:
Top comments (0)