Skip to content

Instantly share code, notes, and snippets.

@graninas
Last active March 18, 2024 14:57
  • Star 249 You must be signed in to star a gist
  • Fork 6 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save graninas/22ab535d2913311e47a742c70f1d2f2b to your computer and use it in GitHub Desktop.
What killed Haskell, could kill Rust, too

At the beginning of 2030, I found this essay in my archives. From what I know today, I think it was very insightful at the moment of writing. And I feel it should be published because it can teach us, Rust developers, how to prevent that sad story from happening again.


What killed Haskell, could kill Rust, too

What killed Haskell, could kill Rust, too. Why would I even mention Haskell in this context? Well, Haskell and Rust are deeply related. Not because Rust is Haskell without HKTs. (Some of you know what that means, and the rest of you will wonder for a very long time). Much of the style of Rust is similar in many ways to the style of Haskell. In some sense Rust is a reincarnation of Haskell, with a little bit of C-ish like syntax, a very small amount.

Is Haskell dead?

There was a time when Haskell was the language to watch. During the late 2000s through the 2010s, Haskell was the language everybody wished they could program in, but nobody did, except for maybe a few people. There were some pretty impressive projects that were done in Haskell. There were massive financial projects done. There were payroll projects that were written in. But perhaps the most impressive from the point of view of a purely functional language like Haskell was Pandoc which had a Haskell core. It slapped in the face the whole notion “Haskell is too slow”, or “Haskell just can’t do real things”. Of course it can, and it did.

What happened? Why did Haskell suddenly, pretty suddenly just stop? It’s certainly not alive now. No one is contemplating major projects in Haskell any longer. Who is a GHC Haskell programmer here? I presume there are one or two people with their hands in the air. The GHC Haskell dialect has kinda fallen into an academic language. No one was really considering anything serious.

Haskell in its time was at the forefront of functional programming. It was the language that kind of characterized or epitomized what FP was really about. There were other languages that were functional, but they were only sort of functional. And of course, I’m talking about languages like Scala, or JavaScript. Those were the two major competitors during the same mid 2000s. Scala, JavaScript, and eventually, Golang, and C++ were followers. Haskell led them. These languages learned a lot from Haskell. Anybody doing Scala now knows that the syntax of the for-comprehension and many of the libraries, come directly from the Haskell world.

Haskell ruled.

It ruled in a way that no other language could have at that time. It ruled technically. There was a productivity which is measured at perhaps a factor of five. A team of developers could get an application written and shipped five times faster than a Scala application, or a C++ application. A factor of five is fairly significant in our world.

Haskell also ruled in ways that were just beginning to grasp. How many of you are using monads? But I’m using monads in JavaScript, and I have a little bit of a monads in Rust. In Go, I can do amazing things with monads. The thing about that is that the Haskell people had that in mid 2000s. There were monads and algebraic data types that were immensely powerful long before most of us even thought about a monad.

Haskell ruled in a whole bunch of interesting ways and yet it died. What killed it?

I’m gonna use a word here, and I don’t want you to take the word the wrong way. The wrong way you could take the word is “evil”, and the other way you could take the word is “ignorant”. But it’s not quite even “ignorant”. The word I’m gonna use is “arrogance”.

There was an arrogance in the Haskell community. Not the evil kind, but the kind that told them that they were somehow better. That the tools they were using were somehow better. That the things they were doing were somehow better. There was the arrogance of those people who believed that victory was inevitable. This was not the slapping your face “you, stupid fool golang programmers” kind of arrogance, although there was plenty of that, too. Instead, it was a kind of arrogance of power. Because the Haskell people were writing a pretty powerful code, they did have a tiger by the tail. It was a powerful compiler, it was a powerful language, and they knew they could work miracles.

And yet, that wasn’t enough. Something insidious, something subtle happened. It caused their separation, they set aside the rest of the industry. The people outside the community who were writing everyday programs began to look at the corner of the eye where the Haskell people were doing: “Emm… Haskell people don’t seem to like us very much, I don’t think we’re gonna like them”.

Some of you might remember the Reddit discussions in the mid 2000s. A bunch of people were there. And they were talking about cool math things there. In those talks, they often were snickering about other languages like Go. It wasn’t anything significant, it wasn’t anything evil, they were just snickering: “He-he-he, mainstream people, ha!”. But I was a mainstream golang guy at that time! I didn’t like that. And I’ve been dealing with language wars in the next couple of years. And I said to them at that time “Do we really want to have language wars on Reddit?”. And the interesting thing about it was not about what they were snickering about, because they probably had a right to do that. What was interesting about is my reaction. My reaction was defensive. My reaction was “Well, you guys, go ahead and do your Haskell thing, but I’m the one who gets real work done.”

That’s the interesting division that got set up at the time. And it was fairly pervasive. There was an attitude among the Haskell community, and again, it’s not an evil attitude, not one that was born out of ill will. But there was an attitude that said “You know, our tools are so good, our language is so good, we don’t need to follow the rules. We can do something else. We don’t have to talk to other people. We don’t have to do the other kinds of programs.” Haskell people didn’t want to do the regular kinds of programs. They didn’t want to have to deal with the corporate database. They didn’t want to have to deal with the horrible schema that had evolved twenty years. It was just distasteful. And they found ways instead to do things like using category theory, and dependent types. They’ve built a wall around themselves, and they’ve chosen to live in a technological bubble. Isolated from the evils of the outside world.

I’m going to define a word here. It’s a word you all know. And this definition is just one of many. You can find other definitions of this word if you like. The word is “professionalism”. And I’m going to define it as “The discipline of the wielding of power”. We have a certain amount of power in our tools, in our languages. But it requires a discipline to wield that power. And it’s not just a discipline in the use of the tool, it’s a discipline in a relationship to the community at large. It is a discipline that says: yes, it is a powerful tool, but powerful tools kill very quickly. And they kill in surprising ways, so we’re going to be careful. And we’re not going to denigrate people who are a little bit less willing to use our smart powerful tools.

Let us redefine “progress” to mean: “Just because we can do a thing it does not necessarily follow that we must do that thing”.

So what killed Haskell is the parochialism, the inability to address the needs of the Enterprise.

Haskell was a stellar performer in certain constraint circumstances but it was limited in its ability or rather in a desire of its users to address the general problems of the Enterprise. There was a certain purity among those people. They didn’t want to step outside and so lead themselves in the soil of real work. There was an “us versus them” feeling of uncleanliness, and those of us on the other side of that boundary felt it palpably. Parochialism is an “Hey you” attitude. It’s a way of putting a big banner on the screen saying “Hey you, I’m gonna do my way and screw the rest of you”. It’s a way to say “We are great in our little domain, and the rest of the world can go to hell”.

What is my save?

I want to save Rust and all other wonderful works that are going on in this community from that same demise. Frankly, I don’t think it’s anywhere near going down that route. First of all, the community is I think more dynamic and larger, and I believe that there is no longer the antithesis “us versus them”. Those of us who are “strong C++ hormonal programmers” have relented. And everybody is looking around and thinking: “You know, there might be something to this Rust stuff.” But still, what is it? What can save Rust from going down the same path that Haskell went?

I’d name 3 things:

The first one is discipline. Discipline specifically in documentation. A technical discipline that can keep Lord Cunningham’s problem from happening. It is writing documentation. And by god, it is a hard thing to do. You just want to write the code. But you should write that damn documentation. I mean all of you have found how hard it is to sit down and say “I’m going to write a good documentation so that others could use my work easily”.

The professionalism of humility is something that may prevent the demise, the same kind of demise that occurred for Haskell. The “us versus them” attitude. No, I know there have been some funny advertisements like “Mac versus PC” thing. “I’m Rails, and I’m Java”. And I don’t think there is any harm in it unless you take it too seriously. Unless you build the wall. Or unless they build the wall in response.

And the last thing would be acceptance of solving the “dirty” problems. Solving the problems of the horrible schema. And we're gonna have to sit down and say “No, we’ll deal with that”. If we’re going to survive in the end, we have to address problems that everybody has. Otherwise someone else will address those problems.

Remember the fate of probably the most powerful and influential language of the 2000s. The language that was at the start of pure functional paradigm, the language that influenced so much of what we’re currently doing. The fate of that language was near oblivion. And the people who used it and loved it had to jump to Scala for a living, and it nearly killed them.

We have great tools in the Rust language. We could kill it by making a mess, we could kill it by being arrogant about it, we could kill it by ignoring the Enterprise. I suggest that we not follow that route.


As one might have guessed, this is not an essay. It's a transcript of the following talk by R. Martin with some substitutions made (SmallTalk -> Haskell, Ruby -> Rust, and others). You are free to make any conclusions from this.

What killed Smalltalk, could kill Ruby, too

@AlohaHenry
Copy link

I think IRC is the one of the typical arrogance XD

@dengyunsheng250
Copy link

agree with it.

@edmondop
Copy link

If Java wasn't killed by EJB, I don't see what can kill Haskell to be honest

@Stridsvagn69420
Copy link

I think the 3 aspects you mentioned are just common sense for programming in general, like don't start stupid language wars and keep things organzied and documented.

And I also don't think Haskell is dead, even if I personally haven't used it yet. There are still projects, be it tiny or large, that use Haskell.
I haven't done anything in it yet, because either other languages were better for the job or I was (and still am) confused by the entire Monad and Functional Programming thing. I'd love to see someone explaining this to me as if I'm five, with pratctical examples.

@hkinke
Copy link

hkinke commented Jun 27, 2023

@Stridsvagn69420 If you come from OOP, you must absolutely change your way of thinking. Data are immutable, function can be a parameter or a return value, and you will often use recursivity to solve problems. Nowadays, most languages implement lambda and/or match expression (C++, Java, Python, Rust, PHP). Monads are like interfaces (as in Java or C#) or traits (as in Rust). A data to be used as Monad, must implement three methods: return, (>>=), and (>>). I recommend to desugar do notation, it is just nest calls. Many languages try to implement their own version of Monad Maybe like Rust (Result and Option), C++ (std::optional). That is very restrictive because you can create your own Monad by implementing the Monad class (interface or trait for other language).

SCALA and OCAML try to mix both functional and object oriented paradigms. The programmer chooses when to use functional or object oriented paradigms. I think F# is a bastard of OCAML. SCALA tries to mimic do notation with for statement, but it is not as powerful as do notation of Haskell.

When you know functional programming, just desugar Haskell notations.

@ssokolow
Copy link

ssokolow commented Jun 27, 2023

Many languages try to implement their own version of Monad Maybe like Rust (Result and Option), C++ (std::optional). That is very restrictive because you can create your own Monad by implementing the Monad class (interface or trait for other language).

Bear in mind that Rust's limitations with regard to monads and do notation are partly due to issues Haskell dodges by having a garbage collector instead of a borrow checker. Just like with how static/compile-time type systems are more limiting for how you can implement things than dynamic/run-time typing, compile-time garbage collection (i.e. ownership and borrowing) imposes greater limitations than run-time garbage collection if you refuse to take the C++ approach of just blindly assuming the code to be correct when it can't be determined for certain.

...that said, I don't know what C++'s excuse is for std::optional.

@bapcyk
Copy link

bapcyk commented Jul 4, 2023

@Stridsvagn69420 If you come from OOP, you must absolutely change your way of thinking. Data are immutable, function can be a parameter or a return value, and you will often use recursivity to solve problems

A function as a parameter or a return value was introduced in OOP (Smalltalk, 1969-1972). Data immutability is available in any programming language and paradigm. But good news: in most languages (including most functional languages) you may modify data in place, in Haskell - no, where you just have to hope for the optimization performed by the compiler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment