

Why is Stack not Cabal? - mcbuilder
https://www.fpcomplete.com/blog/2015/06/why-is-stack-not-cabal

======
Tehnix
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!

------
rnhmjoj
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.

~~~
tpaksoy
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.

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

~~~
codygman
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-...](https://github.com/commercialhaskell/stack/blob/master/.dir-
locals.el)

~~~
kyllo
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")))))

------
heavenlyhash
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 :)

------
rhizome31
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?

~~~
chrisdew
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.

~~~
bad_user
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.

~~~
fjh
> 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.

~~~
sksk
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

~~~
tome
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.

