I read the slides before seeing the talk and I didn’t miss the sarcasm, just letting you know.
I don’t think Haskell has a toxic community or an anti-industry focus. What’s true is that every single community of anything has a bunch of very vocal True Believers. Rust, Scala, C, C++, Java, I can come up with evangelism from every single one of them. So the toxicity you might see in Haskell is… part and parcel. Yes, it sucks. No, you can’t jail every single hooligan in the planet and achieve utopia. Yes, you should strive to do better. No, it’s not an apocalypse. Yes, it’s good to have reminders, I’m not telling you to shut up. No, that’s not THE problem.
So, what do I think is THE problem of Haskell? Why is it not popular in industry? It’s easy to answer. Haskell is hard. Haskell is very hard. For beginners, intermediates, and advanced users.
For beginners, Haskell demands you ditch simple reassignment of state and achieve purely functional means, and demands a firm grasp on recursion. Recursion alone is a roadblock for all newcomers to programming.
For intermediates, Haskell demands you know how to use monads, transformers, lenses, maps, lists, folds, semigroups, laziness, strictness, you name it. No, you don’t have to understand them. Just know how and when to use them. No, no math. No, no category theory. Learning how to use a framework like Servant or an extension like TypeFamilies is something new to learn, like another language. I’m not saying that learning is unfair. It’s not. I’m saying that it is too hard to learn these things. (Yes, other languages have things to learn and also have very hard things to learn too.) It is too time consuming to learn. Some tutorials point to white papers. Some people recommend hundred pages books. You want to set a field on a record and now you’re looking at affine traversals.
You can, you know, just not use these things. But they are everywhere. And profesionally you will have codebases that use them (or so I’ve heard). The complexity eroded by referential transparency returns hidden in increasing amounts of increasingly powerful abstractions.
For advanced users, there is even more to learn. Extensions to try. Build times to reduce. If you don’t have full awareness of laziness and full awareness of what accumulator is what, if you let any invalid state be actually valid because its laziness just slipped through your mind, if something fails to specialize and now it generates thunks and you need to understand specialization… there’s a lot to {-# UNPACK #-}. A good thing though is that concurrency comes practically FOR FREE, it’s actually amazing.
So all people have a hard (long) time learning, this translates to having less horsepower, and this translates to:
- Not having a NetBeans or IntelliJ for Haskell, fully customized to deal with any and all roadblocks. The average Joe is not going to become an Emacs wizard with over 9000 Nix flakes. VSCode is good enough. The Language Server and Cabal/Stack are good, and an amazing effort, but they are actually a expected standard for any modern language. There’s no industrial debugger for Haskell.
- Not having a myriad of small time content to climb the ranks of wizardry.
And the most important one for the average Joe, NO KILLER APPS:
- Other web frameworks are easier.
- The popular game engines are for other languages.
- No enterprise systems like Spring with all its docs.
- Python is easier to understand to act as glue for machine learning done in C.
- There’s no easy GUI to make small apps.
This is not to say Haskell isn’t useful. But there is no Apache Spark for Haskell. There is no Unity for Haskell. There’s probably a parser for your thing in your favorite language. (There is, however, pandoc, to lure some people in.)
And this translates to why industry doesn’t use Haskell. There’s not enough people. You need to pay fair compensation to get wizards to come work for you. They will leave and will need to be replaced. Will you find a replacement? Maybe. It’s too risky. It’s basic risk management. You can deal with splattering trace all over the place to debug a problem, you can deal with records not being ergonomic after years and years of talks, you can slap a monitor to see where all these thunks are coming from, but you can’t deal with non existent people. With Haskell, you can have 10x fun, 10x productivity, 10x reliability, but if the average Joe can barely learn how to write it and maintain it, 10x0 equals 0. So why not use Java? It’s not like we have to recall the 10 million dollar total chips distributed or somebody dies: the customer will complain about the null pointer, we will patch it, fire the scapegoat and hire somebody else for peanuts (free tip: you shouldn’t fire the guy that made the mistake because you fired the guy that just learned not to do it).
So, as you can see, curbstomping toxic evangelism won’t do anything in this regard. The solution is either:
- Improve the ergonomics of Haskell by evolving the standard and adopting libraries that make Haskell easier. This risks breaking industry builds. Of course, you risk changing the language for the worse and pissing off everybody. Easier said than done.
- Make a killer app for Haskell so that people put up with Haskell’s difficulty in order to use it. Easier said than done.
What a tall order, huh?
As for me, I love Haskell, will keep hacking at it, improving at it, and having fun with it.