4 ms·
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 bec
by mhitza 5mo 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 5mo agoThe package manager/build system is anything but decent. Any Haskell project will involve at least 24 hours worth of manual dependency conflict resolution.
- nh2 5mo agoNo, 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 5mo agoPretty 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.