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!
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.
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:
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?
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
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.)
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!