Hacker News Reader

Comment by creichert | Hacker News Reader

It has its difficulties (deployment?) but I'm really enjoying it.

Anything specific? What kind of environments are you deploying in?

Just compared to dynamic languages. Cross compiling and such. I went with docker (see the repo) and it works. Deploys via docker push are a little slower than I'd like but nothing I can't improve later.

I see, it really depends on your goal. The Dockerfile in the repo looks like it's built primarily for Haskell development.

When I'm working with production environments, I build the Haskell executable locally and add that (statically linked) program to the Dockerfile. That should tremendously speed things up. The caveat is that your local and production architecture are the same. I find deploying the static executable much quicker and more simple. You aren't doing it wrong, just thought I would my own preferences.

Some environments like Elastic Beanstalk have timeouts that will kill the build if it doesn't build quickly enough (a problem on smaller VMs). Another issue is potential RAM needed by GHC.

Keep in mind that Haskell executables statically link Haskell libraries and dynamically link system libs (by default). You can find your system library dependencies by running:

    $ ldd dist/build/serials/serials
    [...]

That sounds way nicer than my 30 minute deploy process. I develop on a mac and deploy to ubuntu. How would you recommend I build? Vagrant? (I almost finished getting the vagrant stuff working).

I highly recommend https://github.com/NixOS/nixops, which is good for deployment in general, but especially good for Haskell since the Haskell infrastructure was rewritten this year.

I found myself using cabbage[0] so I could have exact version dependencies. Nix was awesome when mostly using latest versions of a package, but for much of my code I needed specific versions and cabbage allowed me to have them.

0: https://github.com/acowley/cabbage

For the sake of a single manager for my whole system I'll stick with nix. But yes, it would be nice if it knew more about versions. In a future where upstream projects can maintain their own nix packages, I think this will be unavoidable.

I've heard it mentioned several times, but I don't really understand how to use it to deploy haskell code. Do you know of a tutorial link somewhere?

So recently the haskell package infrastructure was overhauled. This is great! But, it means that many resources are out of date.

I really recommend you first read about nix with http://lethalman.blogspot.com/feeds/posts/default/-/nixpills . Once you've done that, the simple instructions at http://wiki.ocharles.org.uk/Nix should get you going.

You can try to skip to the wiki page, but in the likely case something doesn't go quite right, it will be hard to debug without a broader knowledge of Nix.

I'll admit Nix's has quite the learning curve, and I was more tempted to sneak around its uncompromising rigidity than when learning Haskell. But the bitter pill is worth it.

Nix (and NixOS, NixOps etc) is totally, totally awesome (only downside is that it's not a statically typed language itself). Just be warned that it does have a non-trivial learning curve of its own though.

Yeah, It's really amazing that so much of it is not hard coded features but just idioms in nixpkgs. But that might make it harder to learn.

Reply on news.ycombinator.com