Sometimes, the structural tensions within an industry come to a head and manifest as human conflicts: we must take a step back and recognize that violence is not inevitable, by proposing solutions that promote peace, reconciliation, and progress.
Recently, the highly provocative article "Just Fucking Use Go" resurfaced on LinkedIn. The tone is very (very) aggressive, and the author dispenses lessons in pragmatic engineering. In the middle of this manifesto for simplicity, we find this stray bullet:
"No traits, monads, or whatever cursed abstraction the Haskell crowd is huffing this week."
As a lover of functional programming and strict type systems (like PureScript or Haskell), my first reaction was pain and annoyance. Deep annoyance. The kind that actually makes your stomach hurt.
This is exactly the kind of reading you prefer to avoid when you've made the decision to train yourself in FP and have seen its full value (and its beauty, it must be said). How can someone so blatantly despise the mathematical elegance and safety offered by these concepts? It hurts a lot.
So, of course, Haskell isn't the only one getting blasted. Python, Rust, etc., too. Basically, the message is almost like: it's Go or nothing.
But thinking twice about it, I realized that the author and I weren't talking about the same thing, or at least, not with the same imagery or the same pictures in mind. Certain details are important to note, and they allow us to lend a more attentive, more charitable, and more understanding ear to what is being said. In the end, the testosterone-fueled vibe of the article actually made me react positively. Because I can understand him, and I can hear his message, wrapped in a style I respect.
This starts, in particular, with a simple but fundamental misunderstanding in our industry regarding the word "abstraction".
I'd like to dive back into this. And you will see, peace is possible, and even much more interesting than expected. The fruits of gigantomachy dialectics are real.
Mathematical Abstraction or "Dev" Abstraction?
When a functional developer talks about an abstraction (like a Functor or a Monad), they think of mathematical theory. Itβs a top-down approach: you start with a pure concept (Category Theory) and apply it to code to unify behaviors (handling async, errors, or state with the same interface).
When the author (a veteran systems engineer, expert in Go, C, and Rust for low-level network infra) talks about an abstraction, he thinks of mechanical friction, facilitation, code deletion. It's a bottom-up approach: he sees a compilation error, traces it back, and hits a wall of jargon if the pedagogy he encounters is cold and colorless. To him, an abstraction is the number of useless layers of code preventing him from understanding what the CPU is doing, if the code-removed-to-code-added ratio isn't favorable. Nothing magical, nothing shocking. It's legitimate, and healthy.
So what does he mean by "monad" when he writes "...monads, or whatever cursed abstraction the Haskell crowd is huffing this week"?
Monad stacks
The author doesn't hate theoretical reflection (he also codes in Rust and writes eBPF filters, he's no beginner). What he hates is ergonomic bloat.
We have to admit he is right about one thing: in the 2010s, managing Monad Transformer Stacks (layering ReaderT, StateT, ExceptT) in industrial applications was a practical nightmare. It was unreadable, hard to debug, and made it feel like the language was fighting the developer.
A pragmatic Go developer would rather write if err != nil 100 times than have to solve a mental puzzle just to log a line to the console.
He is therefore attacking the developer who glories in using complex monad stacks to flatter their intellectual ego, at the expense of team readability. From that perspective, he isn't specifically attacking monads as a mathematical tool. (Because that's what it is, initially: just a mathematical tool. It was only later that we saw this translated into code.)
The insulting tone somewhat clouded my judgment, and I took offense as a mathematician, not as a developer. He is talking here about the monad as a concrete code abstraction, and not as a conceptual generality of Category Theory. My first interpretation mistake.
Explicit insult or implicit snobbism?
Ultimately, I understand his message and I respect it.
I respect it because his violence has the merit of being explicit. On the flip side, in the academic world of FP, there is often an implicit violence, more university-like, more chic: the violence of treating you like an idiot simply because you didn't check the right box at the right time, or didn't read the right paper before reading the code. This is also a form of violence. The effects of these implicit looks or judgments are extremely destructive to an individual in a career. Some even commit suicide when they feel incompetent or worthless.
Without pedagogical geniuses like Bartosz Milewski (who bridge the gap between pure math and working developers), this kind of violent rejection would be commonplace. And it would be normal. People value their lives and their self-esteem. The industry aggressively rejects theory when we refuse to make it accessible.
So I was wrong to take him for a nuance-less brute. My second mistake.
This is not trivial anti-intellectualism, nor an absolute hatred of abstraction in general: it is a radical critique of fads and the loss of contact between theory and practice. From this standpoint, I cannot disagree. An abstraction can go as far as desired, it is not an issue as long as reality remains the ultimate judge. That's empiricism, and it seems equally healthy to emphasize it.
PureScript: the pragmatic filter on academic research
This burst of anger is actually very timely. Because since then, the community closest to Haskell has engaged in self-criticism.
This is precisely why languages like PureScript exist. PureScript acts, among other things, as a pragmatic filter on Haskell's most theoretical research. It lets Haskell do the heavy lifting, take the hits, and explore the limits of type theory. PureScript waits for things to settle down, evaluates the best parts, and selects the stable abstractions to keep, all while purging the necessary and legitimate bloat (because that's the point) of academic research.
An example that directly answers the author's jab at monads?
Today, with the rise of Algebraic Effects (e.g. via Run in PureScript), the paradigm has shifted on this issue. Entire new languages like Koka or Unison are now being built from the ground up specifically around these concrete ergonomic reliefs. The theoretical power and absolute safety of the monad are preserved, but the syntactic bloat is gone. No more monad stacks. We write flat, readable code, but the compiler explicitly tracks every side effect. The implicit "magic" is dead; controlled explicit behavior has taken over.
In other words, the monad goes back to being a primarily conceptual, confined tool, and stops stepping too much on the developer's toes when typing code. Like the sun: not too far, not too close.
But don't think that peace is easy to achieve: sometimes you have Haskell developers who criticize PureScript's pragmatism because they don't understand the full line of reasoning that led to a particular design choice. It's like democracy: it requires constant work and respect.
Bonus: the 3rd way, speaking about Go
The article has the merit of asking a real question: academic research should not be imposed on the industry without a massive effort on Developer Experience (DX).
Rather than choosing between dumb-but-easy-to-deploy imperative code (Go) and pure-but-mechanically-complex functional code, we can now hybridize them. This is the philosophy behind gopurs, as I explained in my previous article.
It pushes this pragmatism to its ultimate conclusion:
- You write your core business domain in PureScript (to benefit from sound mathematical typing and Algebraic Effects).
- You use AOT compilation to generate a lightning-fast, statically linked Go binary that is trivial to operate.
It's the best of both worlds: the mathematical elegance of a "pruned" Haskell, coupled with the trivial deployment and operational simplicity of Go.
Conclusion
So let's gather the best ideas that are made visible by a gigantomachy, let's understand and forgive the excesses and the insults, and let's build better software.
We're lucky to have one of the best jobs in the world. Let's not tear each other down.
Because coding is about joy, first and foremost.
β€οΈ
Top comments (0)