Leaving Haskell behind

As someone that has also written haskell for about a decade and moved away from it as a breadwinner recently (but for other reasons - I simply wanted to filter job offerings based on social utility rather than language stacks), I definitely agree with the author's first point: the Haskell community values learning extremely strongly. That's great because you work with curious people that have always something to teach and learn. But the community is not so strong when it comes to discard ideas after trying them, and so a professional haskell codebase, if not curated strictly, often ends up with lots of things that you can do but that you probably shouldn't use.

I, however, disagree about tooling. Haskell's tooling sucks, but having used several other languages since (python, js, java, rust, elm), most tooling sucks. After this tour, I miss the Haskell toolchain. Sure, cargo is great, but that's one in many, and most older languages don't have this. I wonder whether Rust can escape this fate as it ages. The author also mentions being dismayed by Python, so I guess that's mostly me seeing the glass half-full though.

In terms of tooling, Haskell has one thing that AFAIK no other language can compete with: Hoogle. Hoogle is amazing. You tell it, in Haskell, what you want, and it tells you, in Haskell, what you can do. It's extraordinary. Someone attempted something similar with Rust, and I even tried to make a Noogle (Nim), but it just doesn't work the same in languages where there's a clear divide between "passing arguments to a function" and "calling a function." I find myself looking at tangles of Rust code with all its Result<Option<Box<SomeEnum<Nonsense>>>, Box<dyn Error>> and I yearn for a Roogle that provides the same level of utility as Hoogle.

Other than that, Haskell's tooling has no redeeming qualities. Nothing (pun intended). A lot of that can be blamed on the community's instinct to make something "innovative" instead of improving what already exists. I feel the author's pain.

> The way that Haskell-the-language evolves — well, the way that GHC evolves, which is de facto Haskell since it's the only reasonable public implementation — is that it gradually moves to correct its past missteps and inconsistencies even in pretty fundamental parts of the language or standard libraries.

I would say that the biggest problem is that GHC is tied to a particular version of base (the standard library). So when changes are made to base, and a new version of GHC comes out that supports only this and not earlier versions, you're forced to change basically all of your dependencies, if you want to use this newer GHC version, as they all depend on base.

I still don't understand why this is necessary. Why must code compiled with GHC 9.6 use base version 4.18.0.0? Why should the binary that is GHC care about which version of the Data.List module the code that it compiles uses? I understand that all the GHC-specific stuff exposed by base is tied to a particular GHC version, but why all the rest?

There is, however, work in progress to split base into multiple packages to fix this (as I understand it): https://gitlab.haskell.org/ghc/ghc-wiki-mirror/-/blob/master...

If I had to choose the three big factors that contributed to my gradual loss of interest in Haskell, they were these:

* the stylistic neophilia that celebrates esoteric code but makes maintenance a chore

* the awkward tooling that makes working with Haskell in a day-to-day sense clunkier

* the constant changes that require sporadic but persistent attention and cause regular breakages

Valid points. Back in 2010-2012, I spent a lot of time learning Haskell. The language itself is great, but the documentation and tooling was challenging to work with. The community went from Cabal (and the infamous Cabal hell) to Stack, and back to Cabal. Overall, the situation has improved.

On the other hand, other programming languages have incorporated elements of functional programming. Take Java, for instance. It has added features like Streams, functions, lambdas, algebraic data types, records, and pattern matching. While Java's syntax isn't as elegant as Haskell's, it does include the fundamental concepts of functional programming.

Many of these reasons are why I moved to F# and haven't looked back (much). I sometimes miss Higher Kinded Types, but F# still has generics and if I'm being honest it forces me to write even simpler code then I would have in Haskell. I generally prefer this outcome.

However F# never feels "leet" like Haskell does. It's like Haskell, but all business. I get a lot done in F# and really enjoy it, but I'll catch myself looking back wistfully, like Haskell why couldn't we make it work. Sigh, the one that got away I guess.

First off, learning Haskell's like trying to decipher an alien language. If you're used to plain ol' if-else loops and straightforward variable assignments, prepare to have your brain twisted into knots. Haskell's got monads, and no, they're not some new type of space monster – they're these weird abstract things that'll leave you scratching your head and questioning your life choices.

Now, I know we all love libraries that make our lives easier. But with Haskell, you might find yourself on a treasure hunt for a library that actually does what you need. The Haskell library scene's like a half-empty thrift store – you gotta sift through a bunch of outdated, half-baked options before you stumble on something that kinda works. And don't get me started on documentation – it's like reading hieroglyphics half the time.

Oh, and performance? Sure, Haskell's got that reputation for being all slick and optimized. But in the real world, you might end up scratching your noggin over why your code's chugging along slower than a snail on a summer day. Lazy evaluation sounds all fine and dandy until your app's gobbling up more memory than it should and moving slower than molasses in January.

Let's talk job prospects, shall we? Unless you're hoping to work on some super niche project for a company that's all in on Haskell, you're gonna have a tougher time finding a gig than a polar bear in the Sahara. It's like showing up to a party where everyone's talking about the latest celebrity gossip, and you're there with your collection of 19th-century poetry – cool, but outta touch.

And let's not forget debugging. Imagine trying to find a needle in a haystack, except the needle's your bug and the haystack is a jumbled mess of functional hieroglyphs. Good luck trying ^^

I have been using Scala. I have found that it can give you the best of both worlds. You can reason algebraically, and often after a refactor, if it compiles, it works. Type inference and monads works great too. You also get to benefit from being in the java ecosystem. In instances where it gets too esoteric, I can break rules and code more like java. I am curious what others think.

It seems to me that the stewards and maintainers of the language actually _intend_ for Haskell to be friendly to research, experimentation and academic pursuit. That is fine, as far as it goes, but obviously this will, at some point, be at odds with the interests of programmers looking to use Haskell as a practical, stable tool. It sounds to me like what is needed is the ability to mark all the experimental, envelope-pushing bleeding edge stuff to a different track (whether through pragmas or even a package level declaration) so that programmers know just by looking at the package whether it's something they want to pull in. This would allow practically-minded developers to adopt a policy along the lines of "we only use Haskell stable" or whatever it'd be called. The dynamic I'm describing is the "Avoid success at all costs" phrase, right? The idea being that if Haskell adoption gets "too high" then the language will become inertial and be unable to continue pushing bleeding edge concepts. What I'm proposing is a way to allow that to happen but also maintain a separate track at the level of the language stewardship that formally acknowledges and recognizes that day-to-day programmers need some way to opt out of some of the edgier stuff and to stay within a more limited subset of stable Haskell.

This is a pretty good post. The weak part of it to me is that I have never felt pushed to use any particular new fancy type stuff if I don't want to. Don't want servant's type-level http apis? Drop down a level and use warp. Libraries are often layered this way because it's understood that excessively complicated types can be a trap. One does have to develop an intuition for how far to go, which will involve making mistakes.

This really resonates with me.

I’ve been using it in a decidedly industrial application for about 1.5 years now. I had some fairly significant experience with it prior (https://github.com/mattgreen/hython).

For the first time in a long time (20 years experience) I’ve needed to learn a significant amount of things. It’s a combo of the domain and the language. It’s rather exhilarating, and also exhausting. Could also be a lot to bite off on with a busy home life too.

Regardless, the language is brilliant. My manager exhorts me to generally write in a top-down manner a lot because Haskell’s flexibility really conveys dev intent well, so think hard about how it should read, and start from there. This is a huge mindset shift from most langs, where you can feel your brain shut off to save cycles as you type “function” over and over. It really feels like it is meant to be write-friendly. Point-free functions are wonderfully terse to write. I joke that TH is my favorite language: a type-checked macro language that lets me write almost anything I want.

And there’s the rub: even with controlled effects via monads, the syntax is still hard for me to scan and read. I don’t know if this comes eventually or what, but this feels like a function of how dense a line could be. I miss early return dearly, and understand why it isn’t a thing (except if you have a MonadZero at hand) but I know it’s a syntactic transformation that won’t make it in. I really miss the amazing Rust LSP. Haskell’s recently lost the ability to flesh out pattern matches due to Haskell internals shifting with 9.x. I still hate and screw up stacking monads. Compile times can be brutal, esp if you hit the lens library. Finally, I’m not a big fan of pervasive laziness: the community has sort of admitted that Haskell programs are far more prone to space leaks developing from this default to the point that many programs may have them go undetected for quite awhile. The systems programmer in me screams out.

I really think the community is one of the strongest group of programmers I’ve ever seen. I don’t want to belabor this and dwell on the big brain memes, it’s more that they think hard on this stuff and actually push forward, vs just telling each other that web frameworks are rocket science and it’s impossible to do better than what it exists.

Ultimately, Haskell fits like a glove for our domain of program analysis. Beyond that, I’d still be a bit wary. I’m still thirsty for a PL that is essentially OCaml but with a better syntax. But that’s just me.

As someone who uses a lot of "core" Java (ie not the messy ecosystem), and gets a lot of really complex stuff done with it, I read these articles about high-tech language features like algebraic data types and ultra-strict typing, and I think, what are these people actually doing? The vast majority of software engineering consists of simple operations that move data from one place to another - from a DB to a JSON file, from a REST endpoint to a browser screen. Is all this machinery really helping? Are you sure?

I recently went to one of the largest Haskell meetups in Europe and pretty much no one used Haskell any more (including some formerly core people), it was almost just a social gathering.

I think in 2023 many of the things that made Haskell appealing compared to other languages before have been widely adopted, while the developer experience and ecosystem for Haskell is as bad as it was. I wouldn't use it for a new project outside of some specific areas.

I just started learning Haskell last year (at my own pace on my own time) and from the minute I wrote a recursive function I understood how freeing and smooth writing in Haskell was going to feel. Once I got used to the new concepts this was going to be like butter...

The two problems I have with it are the archaic standard library and the tooling. Because everything is atomic and strongly typed, you basically have to rote memorize the standard library before you can use any of it. The tooling is just clunky, I can't come up with a better term. The author is right IMO. I haven't been writing it long enough to get the rug pulled out from under me with regard to breaking changes and that, I guess we will see how that goes.

But the language itself... It's like finding this magical thing. I wish Haskell had better tooling and at least more approachable documentation for the prelude.

Hm. Not really convinced by either Ruby counter-example. The first one's ok, ish, but doesn't take advantage of the fact you can pass a block to `zip` so you don't need the `map` call.

The second one's just wrong. You wouldn't use `flat_map` for that if you didn't want indentation, you'd use `Enumerator#product`:

    def all_flavors
      flavors = [:vanilla, :chocolate, :strawberry]
      containers = [:cone, :cup]
      toppings = [:sprinkles, :nuts, :fudge]
      flavors.product(containers, toppings).map { |flavor, container, topping|
        ["a #{container} of #{flavor} ice cream with #{topping} on top"]
      }
    end

While that's not quite doing the same as what `pure` and `<>` do in the Haskell example, the complaint was in terms of visual layout and in that respect it's very similar.

I've maintained a Haskell library for databases for over ten years. Here is my take:

Haskell is a complex and a flexible language. It pushes you toward correctness, but in other dimensions is less opinionated than other languages. If you choose to stay away from the low-level Template Haskell (the types for it are updated often) and the bleeding edge type system tricks, Haskell would be quite stable.

The idea to use only the simple parts of Haskell is great - but what is simple is a rather subjective judgment. Oftentimes the technical choices would be made before the the impact on dev ux and effort to maintain becomes clear. Luckily, doing large refactoring in a complex Haskell project is safe, and improving over the initial choices is easier than in most other languages.

Site got HN hugged (probably):

https://web.archive.org/web/20230824095246/https://journal.i...

It's strange that under any article like this, there's always commentary along the lines of "Hmm, yes, indeed $LANG is bad. What shall we all migrate to instead?"

Reminder that this post represents one person's opinion.

Haskell is still just fine as a programming language for getting actual work done.

If you like Haskell but want something else, you really should consider Scala.

It's not the same. But it has many of the same niceties around the rich type system, but with generally good tooling, the amazingly rich JVM ecosystem (tooling, libraries, learning materials), and a somewhat more pragmatic bent to it.

Scala has a bad rep, justifiably so, due to a lot of its problems in the past: community, libraries, tools, etc. But many of those past problems are much better today. Scala today is a much better platform than it was at peak-hype circa 2015, despite some ongoing warts. Nowhere near perfect, but pretty good overall

I see people in the comments looking for a "better OCaml" or a "industrial Haskell", those folks should definitey try Scala

"I also… don't really want to deal with them on a day-to-day basis. My personal experience has been that very often these sort-of-experimental approaches, while solving some issues, tend to cause many more issues than is apparent at first."

This one really hits home for me

The page appeares to be hugged to death. Google cache: https://webcache.googleusercontent.com/search?q=cache:uWo0Ni...

Interesting. I use Haskell professionally and this article doesn't touch on the most fundamental problem I have with Haskell at all: Function coloring. Basically every monad transformer is different. Just calling basic function from somewhere else can involve lifting. Refactoring is a total pain. Oh you just want to log here but your concrete monad doesn't have a logger? Too bad...

I understand an effect system alleviate this somewhat, so I hope to try this in the future. But holy shit is working with monads annoying.

I want to seriously invest some time into properly learn a functional language.

My goals are simple- write small scripts, solve programming problems in sites like Codewars, Leetcode, Euler Program, etc. And yes, having the "functional enlightenment" or something similar.

Which language should I learn and invest time into? Scala, Clojure, Haskell, OCaml?

This part is interesting:

A good concrete example here is a compiler project I was involved in where our first implementation had AST nodes which used a type parameter to represent their expression types: in effect, this made it impossible to produce a syntax tree with a type error, because if we attempted this, our compiler itself wouldn't compile. This approach did catch a few bugs as we were first writing the compiler! It also made many optimization passes into labyrinthine messes whenever they didn't strictly adhere to the typing discipline that we wanted: masses of casts and lots of work attempting to appease the compiler for what should have been simple rewrites. In that project, we eventually removed the type parameter from the AST

which also seems to conflict with this:

Using data structures indexed by compiler phase is a good example of a “fancy type-level feature” that I've found remarkably useful in the past.

Both of these sound like the "AST typing problem" - https://news.ycombinator.com/item?id=37114976

which I admit I'm a bit skeptical of, because the problem is type safety, and not the compiler's actual algorithm or actual performance.

But I guess the first one is for syntax trees, and the "trees that grow" paper (linked in the article) is for back end passes? Does that change the problem so much?

I'm not experienced with back end passes for compilers, but I personally don't see the problem of using either a Map<AST, ExtraInfo> or a nullable field.

I just hacked on a toy codebase that had the Expr<void> and Expr<T> type safe solution, and it's interesting. But my first impression is that it causes more allocations and makes the code a bit longer.

---

I guess another way to justify the Map is that it's like math -- a "typing relation" is an association from expr to type, so a map or multi-map seems natural to model it.

Haskell continues to punch above its weight in divisiveness. When was the last time you saw an article hating on F#, OCaml or some lisp get this kind of attention?

Haskell hate has an distinguished history. In the 2000s OCaml was "winning" in FP-for-production-apps land, which for no good reason resulted in an outpouring of vitriol for Haskell.

Steve Yegge's joke article comes right at the inflection where Haskell "grows up" and starts offering compelling advantages for production apps, but nobody knows it yet.

The 2010s see real adoption and fervor but no drop in click-grabbing haskell hate. If anything it increases, although the OCaml community buries the hatchet.

So it almost warms my heart to see this still getting attention in the 2020s. Switching to Haskell a decade ago changed my life for the better in every way, so I'd of course rather see Haskell love climbing the charts. But this trend instead supports the thesis that Haskell has "stayed weird", which is probably a good thing.

I could have written this article.

I discovered it around the same time, and it was my go-to language for years and years. I had a brief stint where I wrote it professionally too, but nothing serious.

Eventually I really really got going in the industry and had to use other technologies, namely TypeScript and others. I became pretty fond of those, after getting over the initial hurdles, and didn't really spend time using Haskell at all.

After a while away, I went back to it. One time for a job interview, too. It just .. really lost its shine for me. It just all felt like such academic, ivory tower circlejerk. The ecosystem is still relatively small, the packages in it not always great and almost always have only a single or a couple of maintainers. There are still things missing from the Haskell ecosystem that people wanted over a decade ago. Hell, things like Streaming are still barely a solved problem. There are still popping up new libraries to solve it, and each does more arcane things than the previous in some attempt at getting streaming to be nice, type-safe while also not leak memory and what have you. Most of these end up leaking GHC-isms into their code.

For the most part, I've just taken what FP or Haskell has taught me to other language. Use the type system(but not too heavily) to help maintain your invariants at compile-time. Write small, pure functions as much as you can and compose them to build more complicated functionality.

I've still sort of kept on top of how haskell has been moving, and it seems to me that a lot of Haskell shops have dropped it as well. I think many may have moved to Rust. I don't see myself ever using it for anything serious again. I would much rather use Rust and get much better DX and performance while still being able to write mostly functional code.

I had a pretty similar experience: spent a decade (2007-2017) working professionally in Haskell and just got completely fed up with the state of the language, ecosystem, and community. I migrated most of my new work to Ocaml and haven’t looked back.

For me I think the failure of the Haskell Prime effort to establish a successor standard to Haskell 98 was a big factor: the language and ecosystem became more chaotic and inconsistent over time as people drifted away from any hint of a common standard. Add to that the changes in the community when there were big changes in the cohort of “leaders” who had driven things from the 90s until the early 2010s (eg, when both Simons changed their roles). The folks who took their place haven’t done good things for the language in my opinion.

The author does a good job summarizing ways in which thinking through your Haskell programs is easier than in many other languages. There is a certain straightforwardness to it that, once grasped, is eye opening, appealing and fun.

Haskell opened the door for me to much more rigorous reasoning about correctness.

TLDR: the Haskell programmer who gives a shit has stopped giving a shit.

* http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...

Completely agree with the author. Haskell is a great language but the ecosystem sux. I have a small project that breaks every time I update stack. It really lacks some high quality, bomb proof libraries, like for http for example. Cross compilation is next to impossible, stack also recently broke for using Docker for that.

Cabal is a mess, as is its weird AF format.

cargo is a dream by comparison. I am not happy with some things about Rust either but by comparison it has amazing tooling, and some incredible solid libraries. It also helps that you don't have to be a wizard to get extremely good performance.

> the constant changes that [...] cause regular breakages

Wow, for a language as mature as Haskell I find that surprising. I never really got into Haskell for other reasons, but this one warns me to stay away for the foreseeable future.

For anyone new-language-curious, Idris is a very interesting project that is inspired by Haskell but which seems to have less design drawbacks

I tried to make Haskell work as a product language for a long time - and, until Rust was around, there was really nothing better than Haskell in terms of guarantees.

Haskell is a research language: it's supposed to change and experiment with new things; the permanent in-flux state is by design albeit I wish we crystallised more of the good PRAGMAs as default.

My notes on using Haskell: mostly agree with the article, but I came to embrace rolling my own tooling, some abstraction on top of cabal. I use my abstractions, not what whoever would force on me. Use Haskell as your typed lisp.. with all the pros and cons.

On production use... Don't even get me started. Will work, but need shedding blood.

> the experience of code refactors via algebraic manipulation is still possible in other languages, especially in non-pure functional languages like Scheme or SML

Wouldn't "code refactors via algebraic manipulation" require static types? How would this work in Scheme?

The schism created by the Simple Haskell folks in the community is a rather unfortunate one.

For context, Haskell used to pride itself on being a language where researchers could experiment with industry users on an industrial-grade compiler without interfering with one another. Industry users get new features sooner, researchers get feedback faster, etc. No long revisions of the standards and waiting for implementations to catch up. The evolution of language extensions, specifications, and the standard base libraries have a long history of success with this approach.

However, in the last few years, a group in the Haskell community has felt like they had to push back against the work of these researchers and "protect" the language from adopting them. You end up with folks like the author who feel exhausted by having to argue against adopting these features in code bases they're working on and you have the researchers who also feel exhausted getting constant push back on their ideas and hard work. As this schism has developed it has left people feeling exhausted on both sides where there was once collaboration and community.

Write a style guide. This isn't a problem that's unique to Haskell. You get it in C++ and even Javascript too. If using the entire language is not feasible for your project then state it clearly in a guideline. At the very least it requires contributors to seriously consider their reasons for going against the guide and forces them to justify their changes. The nice way Haskell has done it, from my perspective, is that you basically don't pay any cost for not using those features (caveat being Linear Haskell, but they made it a goal to minimize the impact and I think the cost has been amortized by performance gains in recent versions of GHC at least).

Towing the line against progress in the language seems counter-productive to me. I think there are plenty of language extensions in Haskell to work around the lack of expressiveness in the type system that wouldn't be necessary if the language had dependent types. Learning how to use those extensions and which ones work well together is a whole art that could be greatly simplified by a more expressive type system.

To be fair, I almost never use dependently typed Haskell. And I rarely reach for type level programming... until I can't; usually when I'm writing library code that needs to do stuff with user types... even then, quite rare in practice.

If you sympathize with the author then adopting Haskell may not work for you but I would still consider that there are many technical reasons to use it on a project.

Also, I would also advise folks to avoid telling people they should learn Haskell in order to become better programmers. It's true you have to learn a lot more to go from Java -> Haskell than you would from Java -> C#. However there are practical reasons to be using Haskell that aren't about self-improvement:

- GHC is a battle-tested compiler with decades of industry use that produces some excellent code, has an excellent manual, and has an active community of contributors that are always improving it and making regular releases.

- The concurrency story in Haskell is hard to beat: you want immutability-by-default and STM on green threads. It's excellent.

- The type system is a feature: inference, typed holes, type classes... if you don't have a ton of domain expertise you can still arrive at solutions to complex problems using algebraic reasoning. Clash, Crucible... there are many projects that benefit from having a good industrial-grade compiler that also has an expressive type system.

However I have been using Haskell professionally for a number of years, I maintain a couple of libraries, and I stream myself working on non-trivial Haskell projects for fun and there certainly are drawbacks that I would call out:

- On projects that get into 5000+ modules, build times become difficult to manage and require extensive tooling to stay productive. Haskell does a lot more work than many other language compilers and you have to avoid a lot of features that might be convenient in order to keep build times under control

- Modules are fine but type class constraints can "leak" outside of your API boundaries which can lead to a fair amount of coupling if you're not disciplined about how you approach the design of your type classes.. not really a thing you'll be worried about off the bat though, more of a nitpick

- If you interact with SaaS services chances are you will have to write your own client libraries. For things like amazon AWS you're covered but there are a lot more out there and people don't publish SDK's in Haskell.

"Worse is better" phenomenon.

If you want to get things done, don't use Haskell.

You'll be fighting against the type system constantly. You'll be asking questions on Stack Overflow only to get no response. You'll be rewriting software that's in other language's standard library.

Productive programmers don't use Haskell.

Anyone hiring Haskell devs?

As a Haskell developer, this was hilarious! Thanks for the laughs.

Basically, the author's criticism is that the language is too powerful, too expressive, people try very abstract things, tooling is bad and no one cares about the language.

There is something sinister in this - first, in the author's lamentations about bad tooling. Other languages require linters, formatters, static analysers, etc. because the language's built-in features and type system are sub-par. In Haskell, that's not true, so the lack of "sophisticated" tooling is way less painful.

Second, this is similar to the "equalise things by dragging everyone down to the same level"-type of thinking. It "makes maintenance a chore" because the language allows you to be creative and shoot yourself in the foot! Sure, you can have languages like Go where the language is simple and it's hard to write "unreadable" code, but that comes at a cost of being very verbose, and not allowing for an opportunity to write really good code. Basically, enforced mediocrity. "Hard to maintain" is also used as an euphemism for "this is too complex and I can't be bothered to try to understand it" sadly. I find that quite ironic in the face of all the needless complexity in the software industry (just look at k8s, terraform plugins or the web development stack)... I know way too many programmers like that, who argue endlessly about what is the "most readable", which in practice just means to write the most straightforward, laziest, zero optimisation code, and giving themselves an excuse for that. Even if a less-capable language hinders development (either by making things non-verifiable like no proper optional/nullable handling or simply by making the code more verbose and/or less readable) their advocates justify it on the basis of being standard or "best practice". I think Haskell and similar languages intimidate similar people because they can't shrug and say "well the language can't do that" to justify their laziness, but would have to actually make a reason up to why they don't want to write sound, safe and performant programs.

Third, about backwards compatibility.... this is a "damned if you do, damned if you don't" situation. On one hand, you have languages like C++ and JavaScript which are really backwards compatible, and have really sizable drawbacks because of it. Sure, your code will compile in 5 years most likely without changes, but the language as a whole suffers because of it. There should be a place for languages which are ambitious and aren't afraid to break things. Backwards compatibility is simply a design aspect, not some holy commandment you must adhere to all times.

What are we even doing here.