> every other language which uses a package manager has
  > one that works out of the box without any hassle and
  > without any sandbox tricks.

I have programmed professionally with C, C++, Go, Haskell, Java, Javascript, Python, and Ruby. While this is not "every other language", I feel it's a sufficient cross-section to be useful for the purposes of this thread.

Trying to do any sort of open-source development without a library sandbox, in any language, is madness. OS package managers are completely unable to deal with multi-version dependency graphs. NixOS is no different, unless you want to install the cartesian product of the possible combinations -- how much SSD space do you have?

---

My experience with Haskell leads me to believe that "Cabal hell" is an artifact of certain library developers' API versioning philosophies. Namely, they release numerous libraries all depending on each other with tight version bounds, and change the API regularly. This behavior is fundamentally incompatible with dependency resolution in a compiled language.

Say you have four libraries:

  foo-1.0 depends on bar==3.8 and qux==1.5
  bar-3.8 depends on baz==0.2 and qux==1.5
  baz-0.2 has no dependencies
  qux-1.5 has no dependencies

Then tomorrow you want to release an API-incompatible version of qux and use those new features in foo:

  foo-1.1 depends on bar==1.1 and qux==1.6
  bar-1.1 depends on baz==1.1 and qux==1.5

What do you do here? There's no good choice. Two versions of qux can't be linked into the same binary, and the tight API versioning prevents Cabal from being able to construct a coherent package set.

Now imagine that instead of four libraries, it's O(50), and they're all changing regularly.

Writing lots of tooling and writing manifestos against Cabal sort of helps, for a bit, but it's a lot of work and is deeply unsatisfying for the kind of person who likes to make progress on other goals.

IMO the only practical solution is to loosen the dependency version bounds, and commit to maintaining API compatibility for several releases. I have never encountered Cabal hell when using packages with reasonable versioning philosophies.

To be fair other languages need sandboxes as well: Virtualenv in Python and Bundler in Ruby fill the role

But in a language like Haskell, a sandbox is definitely a subpar solution (glacial compilation times and huge artifacts sizes inside ~/.cabal: 1GB on my machine, compared to the few hundred MB of my ~/.m2). Unless we find a way to bootstrap a sandbox from a vetted/trusted base one that contains things like Yesod (but vetting packages is a job better handled by stackage and/or nix ).

I use Nix, but I'm not comfortable yet in using it with Haskell... to try things quickly I'd need to whip up a nix-shell. But I'm more used to simply have easy access to a ghci repl at my fingertip. And if I install both things, I have to keep care at not trying to cabal install things onto the nix-installed ghc, nor to do the quick-and-dirty thing (go back to install things in ~/.cabal)

Something like lein-try [1] plus Nix might cover my use cases. But Stackage seems simpler and closer to the workflow most haskell developers are accustomed with (and it could be useful also for platforms that don't have Nix available)... if only it'd have more adoption

[1] https://github.com/rkneufeld/lein-try