[freyrs3]

Like many people have pointed out, cabal and npm are not solving the same problem. npm appears to "work" more often because a whole class of problems in Javascript program are deferred to runtime while in Haskell all interfaces have to be compatible, link properly and compile. That's why "cabal hell" is such an imprecise term because on top of the version bound issues it's also used for any and every failure that happens when using cabal, even if it's the library in question that's to blame and not cabal. If you want to consider a similar problem, take 20 interdependent C++ libraries and try to link them into a single application using just version information and see how often that works out of the box.

[nawitus]

You can (and I do) use npm and Node.js with type checking at compile time using TypeScript. Although to be honest it doesn't play that well with different versions of the same type definition, but in principle you could have two header files of the same library and the compiler will create an error on a type mismatch.

[dllthomas]

I think that's only a part of it. I think that it's also the case that the Haskell ecosystem has more breaking changes at the root of diamonds in the dependency graph - which isn't something a build tool can solve (or at least isn't something any build tool does solve).

[sjy]

In my experience the dependency graph often has many more nodes as well. I'm not sure if this is because Haskell code is especially reusable or Haskell developers are especially lazy.

[freyrs3]

There is an ambient culture of code reuse at a level I don't see elsewhere, that's one of Haskell's strength's in my opinion. Though it does make certain packaging problems more difficult.

[dllthomas]

High levels of abstraction and well defined edges mean more opportunities for reuse, which probably contributes to both.