DEV Community: Kevin 心学

🌈 The ultimate polymorphism: PureScript as a universal language (Node's V8, Erlang's BEAM, Chez Scheme...)

Kevin 心学 — Sun, 21 Jun 2026 13:12:49 +0000

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:

👉 Purescript universal multi-runtime benchmark

🍄 The End of Developers in 2026? Elon Musk is right... but wrong.

Kevin 心学 — Mon, 09 Mar 2026 15:02:27 +0000

AI can generate code. But code is not just syntax: it’s a language for thinking about systems. It’s time to clarify why.

In recent years, discussions about software development automation have multiplied. Some technology leaders, such as Elon Musk, claim that developers could disappear. At first glance, this idea seems radical: if AI can generate code from simple natural language instructions, why would we still need developers? It could generate machine binaries too.

Yet this reasoning relies on a very narrow definition of code, where code is seen purely as a translation process, an intermediate step in a production chain:

Natural human idea --Developer--> Code --Compiler--> Phenomenon in the machine world

In short:

Ν --Δ--> C --Κ--> Μ

And we all know that AI (Α) and the compiler (Κ) help us in writing code:

Ν --Δ+Α+Κ--> C --Κ--> Μ

In this sense, coding is only about transforming human ideas into executable binary instructions. On this ground, Musk is probably right: many repetitive or syntactic implementation tasks could indeed be automated.

Ν --Α+Κ--> C --Κ--> Μ

And AI could even do a better job than any compiler (as he said himself). So:

Ν --Α+Κ--> Μ

Ok… that may happen to a lot of companies. Musk may be right.

Note that in this picture, we've lost control. We cannot see what's going on in the machine… Because that was one of the many advantages of traditional code. Right? But anyway, that's another topic.

Let's discuss another aspect of things, and see where Musk is wrong.

The Missing Definition

These debates are very often truncated by a cut (sometimes accidental, sometimes deliberate) in the definitional scope of what we call "code".

Let us put aside announcements, speculative interests, and stock prices for a moment, and focus instead on the definition.

In my experience with functional programming (which I have studied for two years), I (re)discovered another dimension of code. Something absolutely essential.

Here, coding primarily means formalizing an idea, modeling a domain, expressing invariants, and structuring a complex system. In this perspective, code becomes an intermediate symbolic language, a tool for thought, not merely a translation to the machine.

Code as Maths

In FP, code is absolutely not reduced to a translative layer from one language to another, from one world to another. It is an extensive layer of language itself. It is then transpiled (e.g. PureScript → JavaScript).

Ν --Δ+Α+Τ--> Σ --Τ--> C --Κ--> Μ

And here comes the difference. We cannot prune the chain the same way we did before (i.e. remove Δ):

Ν --Α+Τ--> Σ --Τ--> C --Κ--> Μ

Why? Because Σ is a extension of Ν. Not a translation, not another shape, not another physicality we give to a substance. This is the substance itself, going further: Σ > N. It is there to express what Ν cannot express. And guess who does the expression job? Δ. The delta. The difference. The added value. The developer.

AI cannot generate human knowledge outside of humanity. If AI generates Σ autonomously, with tangible results, humans will be interested in knowing them. They will want to know the formula, the symbols that are useful to manipulate reality. There will always be Bob, to check a generated idea. His Σ will then become his new N, and a new cycle of territory extension will begin. It will give him more power on reality. And people who have been ignoring their Σ (letting it to AI) will try to imitate Bob's one, will learn his Σ (which became his N). His Σ will become the new N, for everyone. AI will never generate an everlasting and independent Σ, with no human to catch up with it.

Note that these assumptions are based on an ideal world, where AI is truly capable of validating its Σ ideas. Current practice shows something different. It can barely iterate through several validation cycles by attaching itself to your browser to validate the visual reality of your website. It is impressive, but it is still imperfect. And it is pure 2D virtuality. Nothing to do with reality and 3D-world human stakes.

There will always be Σ. There will always be the need to compress ideas or express something new and interesting for the rest of humanity. We need someone to understand the move: that will not come from the entirety of the group, at the same time. Experts are, in my humble opinion, consubstantial to humans. They will always be there. As long as Ν exists, Σ will exist.

Ν is indeed a social convention. It can grow, it can extend its limits. And Σ is in fact one of the many special corners of Ν. Like math vocabulary, like biology vocabulary… Ν and Σ are two faces of the same cube, and cannot be dissociated. We can invent, with AI help (but only help, by definition), ways of expressing intuitions of Ν into Σ, or vulgarize Σ into Ν. But Ν and Σ are none of AI's real business; they are the very core of human ideas, desires, viewpoints, and knowledge. And they work hand in hand:

[Ν <~~Δ+Α+Τ~~> Σ] --Τ--> C --Κ--> Μ

Σ is richer than English N. More compact, declarative, and precise than traditional code C (it focuses on what, not how).

In Musk’s world, companies will add value if they bring Ν in:

Ν --Α--> Μ

The more efficient they are in providing Ν and helping Α to translate, the more they will succeed. That's why we see numerous tutorials to help us speak to AI, in a sort of infinitely recursive (and sometimes absurd) loop. Just to improve the final Ν in the chain. Of course, the diagram goes far beyond something linear, and becomes indigestible (and costly).

But.

Us humans will still persist information within groups, and make tech companies, to produce Μ. In the FP chain, we can play on Σ, not Ν. That is necessary to add value.

Here, should we call Σ "code"? In my opinion, yes. Because it is not Ν, it is not C or Μ. It is technical, read on screen. It just not the traditional intermediary layer it used to be.

Eliminating code, in this respect, would mean reducing the added value. This is obviously not what the industry prefers.

Code as Expression

It is here that expression becomes central to the modern definition of code. Code is no longer just translation. It is the terrain for expressing particular ideas, with a strong epistemological dimension.

This is exactly what languages like Haskell or Rust enable: code becomes almost an executable specification rather than a mere sequence of instructions. The ability to model and formalize is far more resistant to automation than simple syntax writing.

The AI Wave

In other words, your "protection" against the AI wave lies in your ability to think and formalize a problem correctly. If your language gives you that power, this is the way to go.

Musk is both right and wrong.

He is right with the traductive flavour of code definition.

He is wrong with the expressive flavour of code definition.

The good news is that in this expressive sense, the role of developers remains central. It simply changes in nature. I am inclined to think that this reasoning can and should extend beyond FP.

The rules have changed. But human, expression and "code" are still at the heart of the game.

In the AI village, you'll never be the fool.

🪽 A quiet rewrite of the Web: PureScript on the rooftops of JavaScript

Kevin 心学 — Mon, 27 Oct 2025 13:14:11 +0000

JavaScript became more than code — a culture, a dynasty, a paradox. In the shadow of this legacy, a bold team embarked on an athletic, and deeply inspiring adventure: rewriting everything…

For over decades, web developers have lived in a love–hate relationship with JavaScript, and this has affected their own sense of community, with internal disagreements turning into verbal altercations, sometimes brutal and cruel.
These are the facts. We criticize it, we mock it, we reinvent it — and yet, we often (if not always) come back, partially or not.
Because, deep down, the web is JavaScript (or almost): the lingua franca of the browser, the keystone of everything that runs inside a tab.

And yet… between the endless undefined is not a function, the inconsistent APIs, and the jungle of an evergrowing ecosystem (which can sometimes be overwhelmed by his proposals), it’s hard to find a line of reasoning that makes lasting sense.
So we look for escapes: CoffeeScript yesterday, TypeScript today, Elm or Reason for the boldest.

And now… there’s PureScript — a quiet language (but one of rare elegance).

I know I know, you may be suffering from JS fatigue, like I was (“oh, more promotion from an official team member, infiltrating dev.to…”), and you’re thinking that it’s irrelevant to come up with yet another thing in this saturated universe.

But.

I am a freelance developer, and I do not do any promotion.

That’s when things start to take a turn toward something completely different. It’s not just a thing, a tool, a framework, a bundler… or even a mere language. It’s a parallel universe, both independent and connected, which stands on the shoulders of profound epistemological mathematics. We’ll get back to that.

JavaScript, the Dynastic Dystopia

Let’s face it: JavaScript has won.
It reigns over the web like a dynasty: (almost) uncontested, omnipresent, eternal.
From browsers to servers, from build tools to mobile apps, a lot of things eventually bends to its rule.

But it’s a dynasty with a dystopian flavor: a vast, prosperous empire, yet inherently unstable.
Each new framework promises order and simplicity, but also sows significant additional chaos. Nothing seems to be completely resolved. This is probably what contributes to such dynamism, but it is also what can unnecessarily exhaust some people.
Dependencies multiply, paradigms collide, and peace always seems one npm install away.

You can’t leave this empire, the web is its territory. It holds up, and it does the job — which is no small feat (far from it). And no one is rude enough to claim that there isn’t wonder in many places within this ecosystem.
So what remains?
The art of navigating it: creating your own bubble of confidence, and diving into it fully, without fear.

That’s where Purescript comes in.

PureScript: Haskell for the Great Web (and more)

PureScript is a purely functional language (strongly) inspired by Haskell, compiling down to plain and optimized JavaScript. As such, it encapsulates all the power of Category Theory (remaining dev-oriented), and still can run on browsers, desktop (e.g. Electron), backend (Node), etc.
N.b. Because the subtleties of Node's Event Loop are misunderstood or disliked by non-JS devs, Haskell is sometimes preferred for backend purposes. PureScript has now made these subtleties much easier to handle.

In practice:

Strong static typing — everything is checked before runtime. Functional purity — no hidden side effects.
Readable, efficient output — no black magic.
Powerful type inference — the compiler often knows your intentions before you finish typing.
Algebraic data types and pattern matching — express complex logic elegantly and safely.
Effect system — explicit control over side effects, concurrency, and async behavior.
Extensible records and row polymorphism — flexible data structures without sacrificing type safety.
Typed foreign function interface (FFI) — seamless bridges between PureScript and JavaScript.
Ecosystem synergy — works hand-in-hand with frameworks like Halogen, React Basic, or Concur.
Small, composable abstractions — build large systems from simple, predictable parts.
Mathematically grounded — category theory isn’t decoration here; it’s the backbone.
Cross-platform by nature — browser, Node.js, Deno, Electron, Cloudflare Workers — it just runs.
And… so much more. It’s another world…

PureScript lets you reason about your code with mathematical precision, while still building modern, reactive, performant apps.

It’s the Hextech gem from the Arcane series, the philosopher’s stone, allowing clarity to emerge from a world saturated with conflicting forces.

Writing JavaScript without suffering from it

Take asynchronous effects, for example.

In JavaScript, Promises are convenient but quickly spiral out of control — nested callbacks, silent errors, ghost exceptions.
In PureScript, effects (Effect, Aff) are described and typed explicitly.
No more partial functions. The compiler knows when you’re touching the outside world, and makes you handle it properly.

And yet, you’re still within the JS ecosystem: you can import npm libraries, use React through Halogen or React Basic, or even handcraft JS interop directly. You’re not lost.

PureScript doesn’t flee the dynastic dystopia: it reveals islands of long-lasting structure within it, and ensures their sustainability, development, promotion, expansion, and scaling.

The Art of Compromise: Purity without the Ivory Tower

One of the most compelling aspects of PureScript is that it does not force you to pick a side.
You do not have to choose between the pure, safe, and elegant and the flexible, fast, and pragmatic.

PureScript offers a genuine compromise — perhaps the smartest one seen around this duality.

I’ll let you write everything you love about functional programming (strong typing, purity, composition…), but I won’t lock you in an ivory tower.
If you want to use JS libraries, APIs, or even write some JS yourself, you can.
Just declare a foreign import in one line.
I want you to do things because you understand why, not because I force you to.

This isn’t a weak compromise — it’s a collaboration between two worlds.
You don’t sacrifice native safety or pragmatic flexibility — you make them work together through anti-corruption layers.

There’s no need to throw away your JS experience or deny your love of functional purity.
You can do both — and this upward hybridization is deeply promising: the very best of both world is kept intact.
No downward mixing, no sacrifice, no ideological war between paradigms: just a fluid membrane, allowing the boundary to shift — sometimes to 100% PureScript, sometimes close to 100% JS, if you feel so.

Instead of turning the table upside down, PureScript ensures continuity, compatibility, and a transition without violence.
You could write X(< 100)% of your code in PureScript, and the rest in JS without guilt or pressure.

It’s a rare philosophy: a language that values not just purity, but maturity.

Conclusion: the Web as a playground, not a prison

JavaScript has become the universal runtime. You can’t escape it.
And that’s perfectly fine, as long as you can really choose how to enter it.

TypeScript tries to make JS less dangerous by adding safeguards. And we can thank it for that.
PureScript, on the other hand, comes from a different world, the purely functional one, and builds a bridge to JS. There is no interference, no hidden language design isomorphism, no subconscious mental pollution.

It took me almost 2 years to understand a satisfactory portion of these lands, even in its most remote regions. I read almost every night on this. This is not a small episode: it is an endless series, full of academic work in progress. In any case, the front door is now increasingly easier to open, thanks to high-quality courses made by enthusiasts, and what seemed impossible yesterday has become reality today.

PureScript offers a rare path to achieve your ends with JS: to harness its power without inheriting its potential chaos, to turn its flexibility in a plain quality, to create without betrayal, and to rediscover the joy of writing code where every line does what it says, and says what you think.