Why is Stack not Cabal? | Hacker News Reader

Why is Stack not Cabal?

fpcomplete.com

152 pointsmcbuilder19 comments

It is really great to see all the work being done focusing on deployment of Haskell applications. With stackage for a curated package list, and now stack for a better build tool a lot of things are coming together.

FPComplete is really doing amazing work for the community, especially with not just going around fixing their own problems but actually putting out questionaries to identify what the community as a whole sees as the problem.

I can't wait to see where the community goes in the next couple of years!

I was well aware of the problems of cabal-install but I wasn't sure of what stack is exactly. These finally cleared the thing for me. Thank you.

Exactly. I've been doing some research on Haskell, but Cabal is making it quite difficult for me. I've been dealing with a lot of dependency version mismatches when using sandboxes... I'll definitely give Stack a try after reading this.

For a new project, is ditching Cabal altogether and using Stack recommended?

Well, you aren't ditching Cabal-the-spec anytime soon :)

I didn't know about Stack before reading this, but it sounds very good. Cabal-install has always given me problems.

I definitely recommend at least trying it out, and will do so myself.

For a recent project I did:

    cabal init
    stack init
    stack build

Then I wanted a newer version of persistent, so I opened up my stack.yaml file and added persistent 2.2 to the extra-deps section:

extra-deps: - persistent-2.2

Then I was wondering how to make emacs haskell-mode work with it, and I saw this[0] in the stack repo:

    ((haskell-mode . ((haskell-indent-spaces . 4)
                      (hindent-style . "johan-tibell")
                      (haskell-process-type . ghci)
                      (haskell-process-path-ghci . "stack")
                      (haskell-process-args-ghci . ("ghci")))))

Now everything is working flawlessly and very fast. As a bonus Haskell-mode works correctly for projects I haven't moved to/tested with stack yet.

0: https://github.com/commercialhaskell/stack/blob/master/.dir-...

Same experience here--that .dir-locals.el was absolutely crucial.

In case anyone is wondering how to turn on language pragmas with stack ghci in emacs, I did this for the project I'm working on, because I need OverloadedStrings turned on:

((haskell-mode . ((haskell-indent-spaces . 4) (hindent-style . "johan-tibell") (haskell-process-type . ghci) (haskell-process-path-ghci . "stack") (haskell-process-args-ghci . ("ghci" "--ghc-options" "-XOverloadedStrings")))))

Not yet if it's a Yesod project, because yesod devel is tightly coupled to cabal-install.

Awesome. Great to see the "control the inputs, control the outputs; gain repeatability, gain control" mantra finally moving into the package management and dependency world. If Haskell's next generation of tooling lands hashes and built-in end-to-end integrity as a first class citizen, afaict that'll make Haskell be one of the first communities to really permanently address the "it built on tuesday" problem... and hopefully far from the last :)

Great to see the cabal problem being addressed. It's the main reason I've given up on Haskell.

I'm wondering, is there any plan to support installation of pre-compiled binaries with Stack? (Compiling Haskell libraries with all their dependencies can be quite slow.) Or is it what Nix is for? If so, can I use Nix along with the regular package management of my Linux distribution?

I'm sure this will soon be the next evolutionary step for something like stack or an add-on tool on top of it.

Likewise, I'm now torn between Rust and Haskell as my "safe" language of choice. ("safe" as in - if it compiles, it runs correctly.)

Rust's lifetimes are a bit annoying, its async IO story is woeful, but it does allow safe mutation.

Haskell's more mature, IO is great, and it looks like cabal-hell may be ending, but it is a garbage-collected language.

Have you seen the mio library for async IO in Rust? I haven't used it myself, but everyone that I've asked has had nothing but glowing praise for it (though it doesn't yet support Windows): https://github.com/carllerche/mio

I've used mio and I also have nothing but praise for it, but it is a fairly thin abstraction over epoll/kqueue. That's certainly useful, but it's not nearly as nice or easy to use as the green threads that haskell gives you.

(That being said, I think 'woeful' is a pretty strong word to describe the situation. Sure, Haskell is nicer in that regard, but most other languages aren't.)

GC should never be a "torn between" factor. Either you have a hard requirement that makes GC unusable, or you don't.

That's kind of a false dichotomy, as these languages are applied to different problems.

Speaking of the garbage collector, it was the biggest productivity boost that software developers ever experienced and no matter how many tricks the Rust compiler pulls, the hit on productivity is real. And in terms of the "if it compiles, it runs" feeling, that comes with having an advanced type system. Rust pulls some really nice tricks, but cannot match Haskell. And again, the lack of a GC means the compiler's budget is spent on ensuring that the code is memory-safe, with other things having much lower priority.

> Rust pulls some really nice trick, but cannot match Haskell.

I'm not convinced that's true. Rust is even stricter than Haskell in many respects (first example that comes to mind is incomplete pattern matches, which is a compiler error in rust) and strictness also avoids some run-time errors. I've managed to produce infinite loops in Haskell by accidentally defining recursive values more than once.

While I agree with you about pattern matches in Haskell but for completeness sake there is a ghc flag -W for it. If you compile this code with that flag, you will see the result below:

  --hello.hs
  f mx = case mx of
        Just x -> x
        --Nothing -> "NA"

  main = do
    let v = Just "5"
    putStrLn $ f v

  ghc -W hello.hs
  [1 of 1] Compiling Main             ( hello.hs, hello.o )
  hello.hs:1:8: Warning:
    Pattern match(es) are non-exhaustive
    In a case alternative: Patterns not matched: Nothing

In my opinion, incomplete pattern matches should be an error not a warning, but it seems strange to choose a different language based on that issue.

Reply on news.ycombinator.com