A technical vision for the Haskell ecosystem | Hacker News Reader

A technical vision for the Haskell ecosystem

discourse.haskell.org

108 pointscosmic_quanta38 comments

I was thinking of Haskell recently, why isn't it more popular with AI? Haskell is very terse and token efficient, it has many expressive safety features. Rust is getting additional adoption because of its strictness, so hey why not have this in Rust over Javascript if it takes the same time to write?

An ideal language for agentic AI I would think is extremely strict, where the AI can iterate over the tooling for correctness. It would probably be less verbose and more terse to allow the AI to be more efficient with tokens.

It's as popular as you make it. Nothing is stopping you from using it. People generate code for what they are familiar with or have desire for. There are people who have wanted to give rust a try and AI opens that possibility up. There are certainly less people that want to try Haskell. Furthermore, Rust has more training data so LLMs generally will provide better Rust code than Haskell code. Because of LLM, I'm back into obscure languages that I didn't have the mental capacity to carry day by day. Prolog, Lisp and Forth, and like you said, they are very terse and token efficient. However, I must point out that terse was only relevant prior to the entire thinking era, a model could use 100k tokens to think only to give you 100 tokens of final output.

The ideal language for the AI has very short feedback loops with highly localized errors and minimal up front reasoning about types that itself provides a surface for flailing and errors. I'm not familiar enough with haskell to say for sure but I don't think this describes the language very well.

The ideal language for the engineer driving the agent has maximum comprehensibility, since review and understanding are the real bottlenecks now. I'm also pretty sure this doesn't describe haskell. It incompletely describes rust I think.

It does describe ocaml. And also gleam and maybe scala. And moonbit, developed by someone who is a proven expert in exactly this domain and explicitly targeting this problem space.

I do AI research and mostly work with Lean these days. I love Haskell, though I wouldn't consider myself a particularly strong Haskell programmer (just never spent a ton of time working in it). I think you're spiritually correct that there are lots of reasons to use extremely strict languages with AI, but the reality is a little messier than you'd expect.

Token efficiency is specifically the place where strict languages get a little trickier. With dynamic languages where the model has a ton of training data, like Python, the agents are really good at writing code that just works. You still have challenges there, but they're just different than the challenges you hit with a language like Haskell/Lean/Agda etc. With Lean, for example, the amount that they agent might think it needs to prove for a relatively trivial operation can lead to an absurd amount of code. It sort of plays perfectly towards current agent weaknesses, where agents can run off and reinvent a lot of machinery and build unnecessarily complex abstractions.

And those iterations have a cost. Even if the final artifact is more terse, the path to getting there can involve a huge amount of backtracking and rewriting and off-by-one syntactic corrections.

Ultimately, a lot of this comes down to developer experience. Getting useful error messages for the agent, having fast compile times so that the agent can iterate quickly, providing useful utilities for debugging, etc. There was a popular blog post specifically about Haskell that generally makes this point--the Haskell language is, in a vacuum, ideal in a lot of ways for AI, but the Haskell developer experience and ecosystem made it hard for this team to build with it via agents: https://avi.press/posts/2026-07-10-after-7-years-in-producti...

Note: I am not advocating against using these kinds of language. Obviously, I still work in Lean and a little in Agda and some related languages/projects, so I think this direction is right. Probably biased in that I love them with or without LLMs, but I do think they're also more ideal for AI development. There are still just challenges in getting agents productive in them, and most of the challenges are not about the type systems but the actual ergonomics and dev experience.

Haskell does not have a good low level library wrappers story, unlike Rust.

Nobody prepared it for adoption nearly as much as Rust evangelists did for their language. Years of hard work they invested into maintaining bindings as hobby projects paid off.

There is this memo video of S. P. Jones that famously says "Haskell is Useless". I love Haskell, but I wished it was universal like C, C++, JavaScript, Rust, and C#. By that I mean: It could be used to create apps for desktop, mobile, and web. JavaScript can be used to do so many things like power the entire web, be on node and let anyone create cli and share the code with web, and mobile through React Native, on desktop with Electron and its alike things, it lets you do plugins for god knows how many things, it lets you write things for the GNOME Shell... C and C++ are perhaps behind everything in the world and string theory finally gets seen will see they are written in C. And they can be compiled to Web and almost everything in the world. Rust is a placeholder for the two, and C# reinvented itself when it saw Mono and now works even in the browser. Each time I see Haskell I wonder what else can I do rather than creating CLI apps, and it makes me choose something else that grants me more code reuse and interesting applications.

If I could have a vision for Haskell, it was for it to be useful. Academic research and making compilers is cool, a few cli things here and there are cool too, but why can't we build music players and game engines and flutters and web pages with it? The language is way more elegant and beautiful than all the JS/C like languages out there and I really wished I could use it for the things I did. I'm aware of Servant/Yesod/IHP/Miso/Reflex for web, GTK/Monomer for desktop, TidalCycles for music, SDL/gloss for games, and various FFI/plugin, but none of them feel as coherent and worked on as the others, none of them are polished. Haskell surely needs good DX, but it also needs really better reasons for existing.

So what's missing? GUI libraries?

Nothing is really missing, Haskell can do all of that.

I thought so. What's the reason for the PR problem, then?

It sounds like it needs foundational libraries? Or is it something else. For example, almost everything I write requires one or more of:

  - Embedded toolchain and/or HAL/register map for my MCU family or CPU arhitecture
  - A GUI library and/or basic I/O interaction library (keyboard/mouse to start)
  - A GPU interaction library
  - A web framework (Not going to roll my own DB interface, auth, user system, router, template system etc)

(Etc). I.e., some core library which handles the drudgery I can build my application on. If this is what you're getting at, this suggests a plan of attack!

Pretty sure those all exist; e.g. at work we use Yesod and Servant, which are a couple of Haskell web frameworks.

> There is this memo video of S. P. Jones that famously says "Haskell is Useless".

I think that is an unfair characterization of the video and the intent of Haskell's co-creator, based on the rest of your comment. Simon Peyton Jones makes a graph with two dimensions, useful/useless and safe/unsafe. The question he gets at is: how can one distinguish between effectful and effect-free computations in a programming language? He proceeds to characterize most useful languages as unsafe, and Haskell as useless but safe. He then spends the majority of the video talking about how useful languages are becoming safer, and at the same time how Haskell must become useful.

https://youtu.be/iSmkqocn0oQ

> It could be used to create apps for desktop, mobile, and web

Haskell can 100% be used to create all of these kinds of apps.

whats holding you back? buy claude pro and make it reality, hell im gonna give it try because your comment offends me

It's really hard to be the best at every platform, and at every problem area. Especially at the start. But once you have dominance in some niche, that may give you the power/possibility to dominate other niches.

I think this article tries to figure out where can Haskell be the best.

As for a platform? If Haskell can offer the most secure, correct, and trusted web apps(the biggest platform), created with the help of LLM's, and they can use LLM's to make reading Haskell intuitive, that's a good place.

hasufell has been a wonderful person in haskell land. hes got very clear headed ideas about stuff and so forth.

also the stuff i can now build in haskell with computer aid is epic. earlier this week i stood up what i believe is one of the/ if not the: best step file format reader writer on like every axis. some c ones are 20-30 percent faster on the largest possible cad assemblies i could try out.

an important axis that folks neglect to consider: the main way llms are getting scaled up for better coding is metric megatons of reinforcement learning traces, and type checking thats fancy gives a cheaper and faster training feedback loop.

with an llm as a sortah insane manic intern im looking over the shoulder, so to speak, im able to build the apis and designs i can see but cant type anywhere near the same scale. but i can specify the keystones for the exact designs quite compactly and then the agent kinda acts as a compiler inhave to correct and iterate running

RE the debugging experience in Haskell: we recently wrote a post about bringing live run-time debugging to our Haskell VR compositor: https://simulavr.com/blog/debug-hud/

Live step-through debugging and interactivity we think is pretty underrated in the Haskell ecosystem.

While I agree compile time is a big issue, I think the focus should really be on incremental build, because considering how much work the Haskell compiler has to do, it is expected to be quite slow on full build.

But incremental build has no reason to be slow, if the scope is as fine-grained as the function and type level.

I remember when Charles Hoskinson announced that smart contracts on his crypto platform Cardano / Plutus would use Haskell.

It just didn't get anything like the adoption that Solidity had at the time.

That's not the reason Cardano failed though. All the capital had already established itself on other platforms and "it uses a better language" wasn't enough of an incentive to switch. It's an overwhelmingly common story in that ecosystem, even with other networks that Solidity can target.

Is it even possible for Haskell to have compilation times similar to Go, given the language semantics?

> the onboarding experience of rust

> we are going to build the best onboarding experience in the programming language ecosystem

> This can only be done if we commit to unix principles > write programs that do one thing and do it well

Rust is so approachable because Cargo does not subscribe to "do one thing". In fact Cargo does a bunch of things. Which is very convenient for newcomers, because they only need to learn one thing instead of a bunch (and how they interact).

The same holds for a GUI like a file explorer with buttons and interactions like drag / drop or marquee select, which is a bunch simpler than chaining 3 programs together to delete 30 old files and move some folder into a subdirectory.

It also explains why the most successful tools within the land of Unix philosophy are stuff like AWK, which really don't just do one thing. Or why PowerShell is less usable than GNU. Or why Emacs is an 'operating system'.

It's also a reason why the installation experience for Haskell is so bad: there are a bunch of programs and users don't know where to start and what they need.

> Cabal and Stack: which one should I install? > We recommend installing both.

One thing and one thing well.

Atleast it seems they've added a combined installer for these tools since the last time I've checked.

I disagree. About a decade ago I made some tooling to extract and analyse code from Haskell packages. That's easier said than done, given the use of pre-processors, TemplateHaskell, language extensions affecting the syntax/grammar, using external files like `.cabal` to specify such pre-processors/extensions, etc.

I went through several iterations, to get something that I could throw arbitrary packages at from Hackage, GitHub, etc. The result was a hacky mess containing a GHC plugin to dump Core code, a library to dynamically generate and evaluate strings of Nix to handle dependencies, shell scripts that piped `:t` commands through GHCi, and so on.

It was annoying, not because of the effort involved (I was doing weird, bespoke things; so it's no surprise it needed weird, bespoke code to be written); but because all of the functionality I needed already existed, just buried deep inside GHC/Cabal/etc.

Admittedly the GHC API has gotten much better in recent years; but there's no way the developers of "one tool to rule them all" can predict all of the different things that users will want it to do. Indeed, it's probably wise for such tools to avoid supporting/maintaining particularly weird/niche uses!

Having a collection of tools instead, which "do one thing and do it well", side-steps that problem entirely: users with weird use-cases are empowered to plug things together in a way that suits their needs, without needing the devs to add special features/flags just for them (or maintain their own forks with such flags, etc.)

Sooo they are fixing how you install Haskell? :D

How this was ever a problem ? and today we have ghcup, stack and nix

That's the problem!

If I'm on NixOS, should I be installing via ghcup, stack, or nix?

To be fair, that’s a general problem on NixOS (and other OSes), and one that tools like devenv have tried to solve. You can take what’s included with OS packages, but then you’re stuck with whatever version that is.

> You can take what’s included with OS packages, but then you’re stuck with whatever version that is.

It's pretty easy to override things in Nixpkgs though, whether at the system level, or for one application, or just a particular dependency deep in the tree of one script.

Nixpkgs has a bunch of powerful functions to make this easier, e.g. callCabal2nix, makePackageSet, etc.

https://nixos.org/manual/nixpkgs/stable/#haskell-overriding-...

https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...

The Haskell ecosystem seems obsessed with NixOS in a way I haven't seen anywhere else.

I recall wanting to use Haskell packages that were only available in Nix, but nobody had bothered to make just a normal package.

If you want to create an ecosystem optimized towards correctness, you'll have to curate what you let inside, and drop many things. And Nix is probably the best package manager for correctness.

That of course hurts market share.

They’re pitching a tall order. First they will need to convince the masses that code should be understood.

In before a certain defense tech engineer in 3...2...1

Reply on news.ycombinator.com