upvote

points

by the-grump10 hours ago |
comments
upvoteby mhitza9 hours ago|
next
[-]
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.

reply
upvoteby Pay088 hours ago|
parent|
[-]
The package manager/build system is anything but decent. Any Haskell project will involve at least 24 hours worth of manual dependency conflict resolution.
reply
upvoteby nh26 hours ago|
parent|
[-]
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) 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.

reply
upvoteby pjmlp9 hours ago|
prev|
next
[-]
> - 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

reply
upvoteby jose_zap6 hours ago|
prev|
next
[-]
> 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.

reply
upvoteby drewfax5 hours ago|
parent|
next
[-]
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.

reply
upvoteby mietek4 hours ago|
parent|
[-]
I built an example project showing how to build shared libraries in Haskell, in 2019.

https://github.com/mietek/haskell-so-example

reply
upvoteby mirpa5 hours ago|
parent|
prev|
[-]
Think problem is not in advanced features but in stability, integration and streamlining - compared to Rust/cargo.
reply
upvoteby rootnod33 hours ago|
prev|
next
[-]
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.

reply
upvoteby tome3 hours ago|
parent|
[-]
Do GHC2021 and GHC2024 not do what you want?
reply
upvoteby holowoodman9 hours ago|
prev|
next
[-]
> - 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" ;)

reply
upvoteby lmm8 hours ago|
parent|
[-]
accursedUnutterablePerformIO or bust :)
reply
upvoteby onlyrealcuzzo6 hours ago|
prev|
[-]
> 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.

reply
upvoteby zozbot2345 hours ago|
parent|
[-]
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.
reply