10 ms·

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

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 with the correct algebra. Again models can probably learn to create the right types and orient the solution around that, but it's not automatic - same today as yesterday, laziness is a blessing and a curse. The runtime can do unpredictable things when you suddenly evaluate a deep thunk - GHC directives effectively mean there are multiple "Haskells" Some of those are a result of the "avoid success at all costs" mantra. You can't shake that off in a day. It will take a concerted effort to make it more amenable for seamless adoption. Haskell continues to be my favorite language to write and read, but Rust is the more practical language with a rich type system. If you're looking for something approaching Haskell's expressiveness but with fewer of these issues, check out PureScript.

mhitza 4mo ago
No way tooling is decades behind. You have a decent LSP, debugger, package manager and REPL. Laziness is hard to observe, maybe Strict and StrictData would become more popular in use within this context. I haven't checked in a while now if effects have become the norm in the ecosystem, or if some solution exists for "string" types, but for me all of Haskell's expressivity is lost in the noise of endless conversion function, wrapper types when stacking monads, and import fiddling.
- Pay08 4mo ago
  The package manager/build system is anything but decent. Any Haskell project will involve at least 24 hours worth of manual dependency conflict resolution.
  - nh2 4mo ago
    No, this is not the reality of using Haskell packages. The problem you describe was solved more than a decade ago. You use a Stackage snapshot (https://www.stackage.org/lts https://www.stackage.org/lts) which is a curation of packages that work together, similar to a Linux distribution like Debian, carrying one version per package. Our company using Haskell has not spent 1 minute doing "dependency resolution" in the last 10 years, not has anybody we know.
  - zeendo 4mo ago
    Pretty dishonest take. The most gracious read on this is that you encountered this situation ages ago and assume it's still the case today. I've been writing Haskell in production for almost 10 years now and manual dependency resolution has never been a thing.
pjmlp 4mo ago
> - the tooling is decades behind, say, Rust or Go If only Rust had something like GHCi. Stack and Cabal have longer history than cargo, and Stackage for puzzle dependencies. > - GHC directives effectively mean there are multiple "Haskells" A bit like macro libraries and what features are enabled where in Rust
holowoodman 4mo ago
> - the tooling is decades behind, say, Rust or Go No way. Where vibe-coded Rust contains tons of "unsafe", you can have your vibe-coded Haskell sprinkled with "unsafePerformIO" and "unsafeCoerce" ;)
- lmm 4mo ago
  accursedUnutterablePerformIO or bust :)
jose_zap 4mo ago
> 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.
- mirpa 4mo ago
  Think problem is not in advanced features but in stability, integration and streamlining - compared to Rust/cargo.
  - the-grump 4mo ago
    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.
- drewfax 4mo ago
  I tried building a cross platform shared library. I still couldn't get GHC to generate the library with Haskell's Runtime (RTS) statically linked. Tried multiple AI models and nothing could make it work. Eventually gave up after a month. Also there's no support for Android and iOS, atleast not without spending months in recompiling GHC with haskell.nix or other third party projects. Eventually I switched to Rust. It's tooling is so mature that I can focus on developing than compiling GHC. Despite these demerits, I love Haskell language and lazy eval. I wish I can use it one day.
  - mietek 4mo ago
    I built an example project showing how to build shared libraries in Haskell, in 2019. https://github.com/mietek/haskell-so-example https://github.com/mietek/haskell-so-example
onlyrealcuzzo 4mo ago
> the tooling is decades behind, say, Rust or Go Can AI not help speed this up? As someone who DOESN'T use Haskell... What specifically is it missing? Are you conflating ecosystem with tooling? > If you're looking for something approaching Haskell's expressiveness but with fewer of these issues, check out PureScript Rust is quite expressive. Is Haskell really substantially much more? I do think Rust is a great language for LLMs because I think expressiveness is key.
- zozbot234 4mo ago
  Haskell is more easily compared with e.g. OCaml than with something like Rust. (It's worth noting that OCaml now has its own 'rustified' development OxCaml.) The main practical difference is that Haskell is idiomatically based on lazy evaluation, whereas OCaml is strict. This makes corecursive patterns a bit easier to express in Haskell, but OCaml and OxCaml are friendlier wrt. performance concerns.
  - pjmlp 4mo ago
    Just as Haskell with Linear Haskell.
- the-grump 4mo ago
  That's a fair question. It's part ecosystem, part tooling. The ghcup, stack, cabal mishmash is closer to maven than a tool with a modern streamlined UI like cargo. And yes, Haskell is significantly more expressive than Rust--at the cost of performance.
rootnod3 4mo ago
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.
- tome 4mo ago
  Do GHC2021 and GHC2024 not do what you want?
  - rootnod3 4mo ago
    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.
    - openuntil3am 4mo ago
      Which compiler would you like to use?
      - rootnod3 4mo ago
        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.
    - whateveracct 4mo ago
      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.
whateveracct 4mo ago
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 :)
- xedrac 4mo ago
  [dead]
- rootnod3 4mo ago
  "haskell user smart". Condescend much? And Haskell baking itself to Nix, also not sure if that is a good option. Try compiling that on say OpenBSD or FreeBSD.
  - whateveracct 4mo ago
    Haskell doesn't bake itself to Nix at all. Nix just happens to have multiple pretty mature and usable libraries for packaging Haskell.
alper 4mo ago
> the tooling is decades behind For all the academic interest the language has, it seems very few of those people want to do anything foundational to make the language more ergonomic and more relevant.

mhitza 4mo ago

No way tooling is decades behind. You have a decent LSP, debugger, package manager and REPL. Laziness is hard to observe, maybe Strict and StrictData would become more popular in use within this context. I haven't checked in a while now if effects have become the norm in the ecosystem, or if some solution exists for "string" types, but for me all of Haskell's expressivity is lost in the noise of endless conversion function, wrapper types when stacking monads, and import fiddling.

Pay08 4mo ago
The package manager/build system is anything but decent. Any Haskell project will involve at least 24 hours worth of manual dependency conflict resolution.
- nh2 4mo ago
  No, this is not the reality of using Haskell packages. The problem you describe was solved more than a decade ago. You use a Stackage snapshot (https://www.stackage.org/lts https://www.stackage.org/lts) which is a curation of packages that work together, similar to a Linux distribution like Debian, carrying one version per package. Our company using Haskell has not spent 1 minute doing "dependency resolution" in the last 10 years, not has anybody we know.
- zeendo 4mo ago
  Pretty dishonest take. The most gracious read on this is that you encountered this situation ages ago and assume it's still the case today. I've been writing Haskell in production for almost 10 years now and manual dependency resolution has never been a thing.

pjmlp 4mo ago

> - the tooling is decades behind, say, Rust or Go If only Rust had something like GHCi. Stack and Cabal have longer history than cargo, and Stackage for puzzle dependencies. > - GHC directives effectively mean there are multiple "Haskells" A bit like macro libraries and what features are enabled where in Rust

holowoodman 4mo ago

> - the tooling is decades behind, say, Rust or Go No way. Where vibe-coded Rust contains tons of "unsafe", you can have your vibe-coded Haskell sprinkled with "unsafePerformIO" and "unsafeCoerce" ;)

lmm 4mo ago
accursedUnutterablePerformIO or bust :)

jose_zap 4mo ago

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

mirpa 4mo ago
Think problem is not in advanced features but in stability, integration and streamlining - compared to Rust/cargo.
- the-grump 4mo ago
  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.
drewfax 4mo ago
I tried building a cross platform shared library. I still couldn't get GHC to generate the library with Haskell's Runtime (RTS) statically linked. Tried multiple AI models and nothing could make it work. Eventually gave up after a month. Also there's no support for Android and iOS, atleast not without spending months in recompiling GHC with haskell.nix or other third party projects. Eventually I switched to Rust. It's tooling is so mature that I can focus on developing than compiling GHC. Despite these demerits, I love Haskell language and lazy eval. I wish I can use it one day.
- mietek 4mo ago
  I built an example project showing how to build shared libraries in Haskell, in 2019. https://github.com/mietek/haskell-so-example https://github.com/mietek/haskell-so-example

onlyrealcuzzo 4mo ago

> the tooling is decades behind, say, Rust or Go Can AI not help speed this up? As someone who DOESN'T use Haskell... What specifically is it missing? Are you conflating ecosystem with tooling? > If you're looking for something approaching Haskell's expressiveness but with fewer of these issues, check out PureScript Rust is quite expressive. Is Haskell really substantially much more? I do think Rust is a great language for LLMs because I think expressiveness is key.

zozbot234 4mo ago
Haskell is more easily compared with e.g. OCaml than with something like Rust. (It's worth noting that OCaml now has its own 'rustified' development OxCaml.) The main practical difference is that Haskell is idiomatically based on lazy evaluation, whereas OCaml is strict. This makes corecursive patterns a bit easier to express in Haskell, but OCaml and OxCaml are friendlier wrt. performance concerns.
- pjmlp 4mo ago
  Just as Haskell with Linear Haskell.
the-grump 4mo ago
That's a fair question. It's part ecosystem, part tooling. The ghcup, stack, cabal mishmash is closer to maven than a tool with a modern streamlined UI like cargo. And yes, Haskell is significantly more expressive than Rust--at the cost of performance.

rootnod3 4mo ago

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.

tome 4mo ago
Do GHC2021 and GHC2024 not do what you want?
- rootnod3 4mo ago
  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.
  - openuntil3am 4mo ago
    Which compiler would you like to use?
    - rootnod3 4mo ago
      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.
  - whateveracct 4mo ago
    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.

whateveracct 4mo ago

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

xedrac 4mo ago
[dead]
rootnod3 4mo ago
"haskell user smart". Condescend much? And Haskell baking itself to Nix, also not sure if that is a good option. Try compiling that on say OpenBSD or FreeBSD.
- whateveracct 4mo ago
  Haskell doesn't bake itself to Nix at all. Nix just happens to have multiple pretty mature and usable libraries for packaging Haskell.

alper 4mo ago

> the tooling is decades behind For all the academic interest the language has, it seems very few of those people want to do anything foundational to make the language more ergonomic and more relevant.