Live data from Hacker News

Haskell Foundation 2026 Update

discourse.haskell.org

61–70 of 81 posts

Re: Haskell Foundation 2026 Update

#61

Earlier quoted context omitted.

> cabal build --platform=amd64 It's almost a one-liner + a nix derivation import, works within a minute on incremental builds even on large projects: https://input-output-hk.github.io/haskell.nix/tutorials/cros...

but does it require installing nix on mac? also many people are not familiar with nix and brew does all i need.

> but does it require installing nix on mac?

yes:

    sh 
https://nixos.org/download/

> also many people are not familiar with nix and brew does all i need

it's a good reason to learn Nix then: it will completely replace your brew and offer an ultimate build tool suitable for any software stack moving forward. And you'll get cross-platform and static Haskell builds.

Re: Haskell Foundation 2026 Update

#62
post #52

Earlier quoted context omitted.

I think the GHC directives are what hurts Haskell the most. At this point they should just embrace the GHC extensions and make it the "official" Haskell. Having to enable them in the code is just a hassle. Just make it official and be done with it, just roll it into the language.

Do GHC2021 and GHC2024 not do what you want?

Again, those are _GHC_ extensions, not "standard" Haskell. At this point it's not Haskell, it's Glasgow Haskell.

And those features are not a library that you just throw in, they are compiler specific.

Re: Haskell Foundation 2026 Update

#63
post #42

Earlier quoted context omitted.

> the tooling is decades behind, say, Rust or Go That's definitely not true, even if that was true maybe 6 years ago. As someone who's uses Haskell daily and also many other languages, I can see Haskell's tooling as more advanced than many others.

Think problem is not in advanced features but in stability, integration and streamlining - compared to Rust/cargo.

This is exactly what I meant. It's not the ability to build things; of course you can.

The progress has been in agreeing on a coherent interface everyone uses and which handles 99% of what most projects need with minimal friction.

Re: Haskell Foundation 2026 Update

#64
post #52

Earlier quoted context omitted.

Do GHC2021 and GHC2024 not do what you want?

Again, those are _GHC_ extensions, not "standard" Haskell. At this point it's not Haskell, it's Glasgow Haskell. And those features are not a library that you just throw in, they are compiler specific.

Which compiler would you like to use?

Re: Haskell Foundation 2026 Update

#65

Earlier quoted context omitted.

Again, those are _GHC_ extensions, not "standard" Haskell. At this point it's not Haskell, it's Glasgow Haskell. And those features are not a library that you just throw in, they are compiler specific.

Which compiler would you like to use?

Preferably there would be more implementation. But if they only implement the "standard" language, it will be missing a lot of things. That is the point! It's not Haskell anymore. It's Glasgow Haskell. It's its own language at this point.

Re: Haskell Foundation 2026 Update

#66
post #57

I found Haskell too difficult. They focus on a specific niche, so they won't be a mainstay programming language anyway, but even then when you ask people what are the real innovations or success stories per given year, say, 2025 or 2026, they almost never mention Haskell.

On the other hand, the language is already 35 years old and people still use it! Many other languages have died in the meantime.

What kind of argument is that? Java is 31, Python 35 years old, and Lisp is almost 70. They all still being used. Come on, let's find something real to talk about.

Re: Haskell Foundation 2026 Update

#67

The thought crosses my mind that Haskell may be uniquely suited for AI coding using a very small context window (cheap). Haskell encourages small functions and no global state. So you may be able to capture all the relevant context for editing a Haskell function within a few hundred or few thousand tokens. That would be better than some other languages. Plus the strong typing could help AI agents catch errors. I have…

[dead]

Re: Haskell Foundation 2026 Update

#68

I found Haskell too difficult. They focus on a specific niche, so they won't be a mainstay programming language anyway, but even then when you ask people what are the real innovations or success stories per given year, say, 2025 or 2026, they almost never mention Haskell.

monad transformer stacks

Re: Haskell Foundation 2026 Update

#69
post #52

Earlier quoted context omitted.

Do GHC2021 and GHC2024 not do what you want?

Again, those are _GHC_ extensions, not "standard" Haskell. At this point it's not Haskell, it's Glasgow Haskell. And those features are not a library that you just throw in, they are compiler specific.

who cares

the only other haskell compiler is MicroHs. and it has no pragmas. it just enables the whole thing.

this is not a real problem in practice. even without the GHC20XX stuff (which is nice). it feels like a problem a novice would point at (and be totally wrong)

sorry your favorite language doesn't let you import language features according to your needs. half of them have trade-offs! like -XOverloadedLists. Useful, but hurts inference. Maybe you don't want it globally. But maybe in a few modules, it's perfect. {-# LANGUAGE OverloadedLists -#} is the answer that no other mainstream lang has.

-XPolyKinds is another great example of that sort of extension.

Re: Haskell Foundation 2026 Update

#70

The thought crosses my mind that Haskell may be uniquely suited for AI coding using a very small context window (cheap). Haskell encourages small functions and no global state. So you may be able to capture all the relevant context for editing a Haskell function within a few hundred or few thousand tokens. That would be better than some other languages. Plus the strong typing could help AI agents catch errors. I have…

As someone who loves Haskell more than any other language, some challenges are - the tooling is decades behind, say, Rust or Go - finding the right library in looks very different in Haskell--you frequently start with the signature on Hoogle. Agents can learn this but it's not the same as "web search" - creating the right solution also looks different. It's usually borne out of thinking about the types and coming up…

cabal is as cargo-level but has a bad CLI. it really isn't that bad. and Haskell has amazing Nix support. Like 3 different good options there depending on your project.

and this isn't even to mention stack..

now, if you're a not smart enough to handle there being many options existing in a world of trade-offs..haskell was never for you :)

Post reply on HN