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

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...

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

That of course hurts market share.

https://leangineer.com/blog/realworld-in-lean/

https://news.ycombinator.com/item?id=50088748

though i have thought about it.

>Languages

>Haskell 81.9%

> 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 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.)

One other wrinkle is laziness by default. There are good reasons the language was done that way and strict isn't inherently better. In fact you'd give up a lot moving to a strict by default / laziness optional language. That said, laziness can make it hard to reason about performance. Experienced Haskell devs can do this but it still requires a lot of mental effort.

I suspect these two items are the primary ones. There are others. But I absolutely love the language even if I have never had the opportunity to use it professionally.

  - 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)

- Copilot (by NASA)

- MicroHs — for running Haskell on an MCU

GUI library and/or basic keyboard/mouse I/O:

- Monomer

- sdl2

- gi-gtk4

GPU interaction library

- OpenGL bindings

- vulkan bindnigs

- Accelerate — numerical GPU computation with an NVIDIA backend.

Web framework with database access, auth, users, routing, and templates:

- IHP

- Yesod

I think that is an unfair characterization of the video, 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

The famously friendly "Learn You a Haskell" book features its first "helloworld" program deep into the middle of the book, _after_ functors and (if I recall correctly) monads. It takes a very special beginner programmer to push that far through, working in the REPL, before they can write programs that do basic I/O.

I teach functional programming to college sophomores and juniors, and I would love to teach them Haskell. But I have to meet them where they are, and it would be difficult to do in Haskell. This is why we have taught either F#, Scala, or LISP over the years. F# in particular has a lot of the aesthetic qualities of Haskell while allowing impurity or mutability escape hatches without too much trouble. If somebody has truly beginner-friendly Haskell resources, I would love to hear about it-- I'm apparently not smart enough to chart that path myself.

It is important to clearly understand that Simon uses the word "useless" in the sense of having no side-effects on the external world i.e. if state changes are not reflected in the external world at some point then there is no practical purpose to it and hence "useless".

Functional languages solved this by using the type system at different levels to combine both effectful and effect-free computations cleanly.

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

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.

...

> Haskell surely needs good DX, but it also needs really better reasons for existing.

Man am I tired of people dropping negative crap like this any time Haskell comes up, especially when they end up at the top of the comments. It ends up derailing most conversations about Haskell that aren't on explicitly Haskell-focused forums, and turns every post on Haskell elsewhere into a referendum on the language itself. FFS the post itself is explicitly about polishing up the technical infrastructure _to achieve what you're complaining Haskell doesn't have_ and all you can do is shit on Haskell in response: "We want to improve the developer experience!" You: "No one wants to use Haskell because the developer experience is so shit!"

Put your money where your mouth is and do the polishing you're complaining about if you actually give a shit about Haskell. Fucking make something! Nothing is stopping you. Haskell is useful right now. I have personally been building a home automation system for it that uses Lua, MQTT, STM, and more that I have been running nonstop in my home for literally years now and it's absolutely awesome to work on and it's rock solid--partially because Haskell does an amazing job of helping me avoid bugs and provides a wonderful refactoring experience, which is a huge part of its reason for existing thank you very much.

All comments like yours do is dissuade others from taking a look at the Haskell ecosystem by implying it's a pointless language; it steers people away, as the main takeaway is that you can't actually build stuff in Haskell and so why would you want to use a language that you can only build CLI apps in? (Absolute bullshit btw.) As someone that cares about Haskell and spends my time actually building stuff with it, I just read posts like this and shake my head. You absolutely can use Haskell to make things, and insofar as Haskell doesn't get used (distinct from being useless) and has a ton of sharp unpolished edges remaining, it's the fault of posts like yours as much as anything. Either get involved or give it a rest and go use the other languages you seem to prefer. You aren't treading new ground with this comment.

Sorry to swear so much but that really pissed me off

https://news.ycombinator.com/item?id=15486063

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

But incremental build has no reason to be slow.

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

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

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.

I mean, free functions and no general nice trait/struct/enum based architecture, random `Mutex`/`RwLock` everywhere, all your big futures inside a `tokio::select!` etc.

Yes it's great when you do your first Rust project. After a year it's a nightmare if you don't keep a clear control how the code is generated and organized.

The ideal language for the engineering 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 doesn't really describe rust either.

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

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...

> 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.

I'm confused how the former supports the latter here.

Surely, you mean that LLMs are not the right kind of "AI". Languages like Haskell expose how fundamentally porous LLMs are with information.

Admittedly I'm not much better, Agda has some crazy scoping rules at times and its operators are a mess, so much worse than Haskell, but at least I don't have to re-learn from scratch after every compaction.

So, I could write what I want in haskell, and it's faster for me than to have an LLM do it. The haskell would be high-level enough and precise enough to describe what I want the program to do with less iterations than I'd have with an LLM writing code, finding its own bugs, fixing them, then having me ask it what it did, tell it what to do differently, etc.

Direct control is very powerful. LLMs take that away from us, in exchange for a great speedup. But perhaps we can use LLMs to give it back to us by making our actual programming languages more powerful.

Here's one rough example that is related to this direction:

A common convention in Lean is to write essentially two versions of a function, with a theorem proving their equality or correspondence.

So you can write a more demonstrative version that is more easily understood, which you can treat sort of as a spec that all other implementations must satisfy. And then you can set the agent loose to do whatever nastiness it wants to do to improve performance.

Here's a fun write up from someone doing just this with zip file compression: https://kim-em.github.io/blog/2026-7-24-why-lean-is-faster-t...

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.

My former company was generous enough to publish most of these[0] as open source projects. But what's really telling is that oftentimes vendoring a commonly used OSS library was unavoidable.

[0] Here's a potentially incomplete list: https://chatgpt.com/s/t_6af76fd8f2a081918fa37f8c30bdb3ba

That's doubtful. It's not strict in any way that matters, especially when LLMs are writing it. You still have to rely on tests for everything.

It is seeing adoption because of a well executed advertising campaign combined with it being "C++ without the dependency hell".

In fact if I have to ship in a different language, I'll often do a Haskell version first to steer towards isolating IO, enforcing referential transparency, and generally picking up other functional patterns that are a good idea no matter what. Then I'll port the Haskell version to whatever the solution demands.

As lower-hanging fruit, to get some style steering, but not the strictness/correctness assist in implementation, there's also doing code sketches in hs - writing without testing - and then asking for whatever code as inspired by / in the spirit of / based on the reference sketch.

The benefits of strict are still the same: once the code grows bigger you have alll kinds of guarantees built into the software, that JS/Py/Bash/C needs lots of test achieve the same.

Since writing code is cheap, it like to go more on the tests and the strong typing, simply because it is so cheap. Why write Ruby/Py/JS when you can write Haskell/Kotlin/Rust? There's simply no reason not to be doing TDD these days.

"higher level projections" - wtf is this even about?

I used prolog for a project and GPT 6.1 Sol repeatedly made dumb mistakes as if it doesn’t understand the symbolic resolution capabilities.

For vibe coded Haskell id not be surprised to see it just not use strict types, hucking strings around

Data from: https://agentduel.com/leaderboard

A priori, it does seem strange. But the relative Haskell vs Python tokens in the internet go a long way to explaining it, as another commenter has said.

[1] https://danluu.com/pl-tokens/

OK, so I put this into Gemini: "show me a non-trivial haskell function and type signature with at least five distinct arguments"

And I get:

---

processRecord :: (a -> b) -> Maybe c -> [d] -> (e -> Bool) -> (b, c, [d], e) -> Either String (b, c, [d], e)

processRecord transform mVal items pred (bVal, cVal, dList, eVal)

  | pred eVal = Right (transform (const bVal undefined) mVal, cVal, dList, eVal) -- simplified example logic

  | otherwise = Left "Predicate failed on the fifth argument"

My brain just crashes after the "::".

For the beginner, there isn't enough syntax on offer to discern who's doing what to whom here.

Is there a "function signatures for dummys" somewhere?

-- Here you go

-- Oh my god, it's non-trivial

If someone told me German was easy to learn, I wouldn’t get an LLM to generate me a complex sentence with two clauses and three adjectives and then be like “sure about that?”

`processRecord :: (a -> b) -> Maybe c -> [d] -> (e -> Bool) -> (b, c, [d], e) -> Either String (b, c, [d], e)`

Says: “ give me: 1) a function of a to b, 2) a ‘c’ wrapped in a Maybe, 3) a list of d’s, 4) a function of e to a Bool, 5) a 4 tuple of a, b, list of d’s, and an e

And I will give you either a String or your original tuple back”

It doesn’t really do anything so there’s not much more to explain

If I ask my grandma what she thinks of the supposedly easy Python syntax, or C-style curly braces, her brain would similarly crash. Unless she read an intro to Python or C first.

In other words, do not confuse "I'm unfamiliar with this because it doesn't resemble what I know" with "hard to understand".

Some languages are here merely to inspire others.

Not that Elm is such a success... But it is "simple" (Haskell and Perl are not; they big).