4 ms·

The reason I ask about package management is because when I do my annual try-to-use-Haskell-for-real event, I pick either Stack or Cabal, inevitably run into is

The reason I ask about package management is because when I do my annual try-to-use-Haskell-for-real event, I pick either Stack or Cabal, inevitably run into issues with one and have to switch to the other. Plus I've had situations where I tried to install packages and the manager gave me the computer equivalent of a shrug. Contrast that to Cargo which works beautifully and seamlessly out of the box. However I hold out hope that Haskell is getting better and easier to use. Legitimately, this tutorial's code looks a lot better than what I've seen before. But I'm still dissatisfied with the level of naming and documentation. I get it that the names may have been obvious to the author, but it's a little worrying to me that the author didn't think about this fact when writing the documentation. Plus Spock isn't a young framework. It's my belief that anybody writing a package should know that interface names are designed to be readable and understandable. And these names aren't subtly hard to read. HVectElim just isn't a great name. That being said, I don't want to just hate on the Haskell ecosystem. I do really find the language fascinating. I just want some better documentation, more tutorials and nicer, unified tooling.

verttii 7y ago
Stack uses cabal underneath though. What kind of issues are you running into? Personally I love the language but struggle with all the (necessary) stuff around it. Configs, deployment, dependency management, editor setup, lint, auto-formatting... Everything feels unnecessarily painful.
- _hardwaregeek 7y ago
  Generally issues where package management just fails. Also it's just overall not ergonomic. I end up installing yet another version of GHC a lot (I believe that GHC version should be handed separately from package versions like rustup/cargo, nvm/npm, rbenv/bundler). But this info could definitely be out of date. I might be due for another try at Haskell
  - defanor 7y ago
    Not sure if it became much better in the past few years; I seem to run into issues less and less often (and all were solvable rather quickly), but it may be simply because of the avoidance of problematic packages and approaches. Here is a bit more of information though: - Cabal 2 supports Nix-style local builds [1]. - Stack seems to aim very smooth and easy workflow. Though it didn't work well for me when I tried it (I think I had a version that was too old, and was rather appalled by the way they suggest to install a new one, with `curl ... | sh`). And as mentioned above, I prefer the opposite of adding even more layers on top of cabal and using multiple package managers, in part because it introduces more ways for things to go wrong. Likewise with Nix outside of NixOS. - I used to find Cabal sandboxes helpful, but not using them these days. Different versions of the same package can be installed simultaneously, if it becomes tricky to stick to a single version while using Cabal. And as the last resort one can wipe out the local package database. - Careful versioning could solve some of the package management and dependency resolution issues, and there is a common package versioning policy [2] (similar to, but not exactly the same as semver), but not everybody follows it (in versioning their packages or in pinning dependencies); one should be careful with packages that don't. - Minimizing dependencies can be useful for this, among other things. Without keeping an eye on it, one can easily find themselves in a dependency graph with hundreds of packages, often coming pretty much directly from developers (without additional package maintainers keeping an eye on them following any standards or being compatible, though it's supposed to be better with Stack), some of which may misbehave at some point. - On some systems it is viable to use a system package manager for Haskell package management. But possibly my experiences are not representative either: as mentioned before, opinions and approaches around it tend to vary. [1] https://www.haskell.org/cabal/users-guide/nix-local-build-overview.html https://www.haskell.org/cabal/users-guide/nix-local-build-ov... [2] https://pvp.haskell.org/ https://pvp.haskell.org/

verttii 7y ago

Stack uses cabal underneath though. What kind of issues are you running into? Personally I love the language but struggle with all the (necessary) stuff around it. Configs, deployment, dependency management, editor setup, lint, auto-formatting... Everything feels unnecessarily painful.

_hardwaregeek 7y ago
Generally issues where package management just fails. Also it's just overall not ergonomic. I end up installing yet another version of GHC a lot (I believe that GHC version should be handed separately from package versions like rustup/cargo, nvm/npm, rbenv/bundler). But this info could definitely be out of date. I might be due for another try at Haskell
- defanor 7y ago
  Not sure if it became much better in the past few years; I seem to run into issues less and less often (and all were solvable rather quickly), but it may be simply because of the avoidance of problematic packages and approaches. Here is a bit more of information though: - Cabal 2 supports Nix-style local builds [1]. - Stack seems to aim very smooth and easy workflow. Though it didn't work well for me when I tried it (I think I had a version that was too old, and was rather appalled by the way they suggest to install a new one, with `curl ... | sh`). And as mentioned above, I prefer the opposite of adding even more layers on top of cabal and using multiple package managers, in part because it introduces more ways for things to go wrong. Likewise with Nix outside of NixOS. - I used to find Cabal sandboxes helpful, but not using them these days. Different versions of the same package can be installed simultaneously, if it becomes tricky to stick to a single version while using Cabal. And as the last resort one can wipe out the local package database. - Careful versioning could solve some of the package management and dependency resolution issues, and there is a common package versioning policy [2] (similar to, but not exactly the same as semver), but not everybody follows it (in versioning their packages or in pinning dependencies); one should be careful with packages that don't. - Minimizing dependencies can be useful for this, among other things. Without keeping an eye on it, one can easily find themselves in a dependency graph with hundreds of packages, often coming pretty much directly from developers (without additional package maintainers keeping an eye on them following any standards or being compatible, though it's supposed to be better with Stack), some of which may misbehave at some point. - On some systems it is viable to use a system package manager for Haskell package management. But possibly my experiences are not representative either: as mentioned before, opinions and approaches around it tend to vary. [1] https://www.haskell.org/cabal/users-guide/nix-local-build-overview.html https://www.haskell.org/cabal/users-guide/nix-local-build-ov... [2] https://pvp.haskell.org/ https://pvp.haskell.org/