
Haskell developer experience in NixOS - allenleein
http://www.kuznero.com/posts/nixos/haskell-devexp-in-nixos.html
======
marmaduke
I'm not a Haskell developer nor Nix user, but I find Docker is surprisingly
convenient, if only for its immutable layers file & build system: as I test
different packages, I only pay for what's changed or removed, not the full
setup. For example, for a C library, you might start with

    
    
        RUN apt install -y build-essential
        RUN apt install -y libopenssl-dev
        RUN cd src && ./configure
    

but if libopenssl-dev is the wrong package, change that line, and rebuild, and
the build-essential installation isn't redone, only what's change and
subsequent lines.

Any sort of snapshotting at file system level (e.g. ZFS) would do the job as
well, but Docker puts it together in a convenient way.

I guess Nix is better by using a DAG, but it's probably more complicated and
harder the reason about (at least for those of us lacking in headspace).

~~~
bennofs
Docker is a nice runtime, but you cannot reproduce the build of a docker
container. What if you want to make a small change to the image? You need to
rebuild it, but if it's years later, the versions of packages in the ubuntu
repository may have changed and a lot of other things (if you're not careful,
tarballs downloaded during the building of the image may have
disappeared/changed/...). While you can try to avoid these through careful
scripting and pinning things, this is what Nix makes really easy: just pin
your nixpkgs version, and you can almost guarrante that you'll get the exact
same build years later and you can still change parts of it if you need to.

~~~
jrs95
Could reproducible Docker builds be achieved through adding Nix, then? Maybe
that really ought to be the best practice for people doing this on a large
scale.

~~~
Filligree
It already has all the needed infrastructure, in fact. See for example
[http://lethalman.blogspot.ie/2016/04/cheap-docker-images-
wit...](http://lethalman.blogspot.ie/2016/04/cheap-docker-images-with-
nix_15.html)

------
popinman322
This is mostly about NixOS and not the Haskell experience (though some of this
applies to that as well).

TL;DR: I install a lot of packages to try them out and want an easy way to
roll them back with as few consequences as possible. Nix seems to fill that
gap.

As a student this really appeals to me; I usually think in broad terms
initially, maybe write a proof or two to make sure I'm doing what I think
(read: hope) I'm doing. Implementation is an afterthought for me, and so when
it finally comes time to implement something I'll usually start at the typical
"what are my options" phase.

For domains that I'm strong in I have a good idea what's available and it's
probably already installed. But sometimes you're just /new/ to something and
need to try things out. Sure, an API seems good in theory, but how does it
work out in practice? Too much boilerplate? Does it work well with everything
else I want? Did/does the original author share similar use cases to me? Is it
(well) maintained (still)?

Of course, by the end of this process any number of things could be installed;
both things I asked for, and things I didn't, are available to me. The issue
that I then run into, and that Nix seems to solve for me, is that I want to
undo portions to the installation and all their unintended side-effects.
Beyond that, an easy way to manage groups of packages and roll them back en
masse (again, including unintended side-effects) would be so beautiful.

In the case of Haskell, I have created chroots just to keep Haskell penned
away from the rest of my system. I don't need pacman yelling at me because I
`cabal install`d something and now the owner is wrong, my hair is on fire, and
the universe is imploding. Nix seems like a much better way to handle this.

Of course, I could just be naive and/or uninformed-- likely both. I'd welcome
sage wisdom from Haskell programmers on how to properly, cleanly manage
package installs without getting in trouble with the system package manager
(short of creating packages myself). And I've no doubt this has been solved
outside of Nix using methods beyond rigorous self-control.

~~~
emj
The mess you describe is only a problem if the products you produce suffer;
chroots, virtualenvs and Snaps are a nice way to handle the resulting problem.
If Nix really does make you more productive then sure this is a great way to
solve this, but for me I would still have to convert that Nix environment to
something shipable.

~~~
nextos
You can ship Dockers built with Nix. It's actually a great and quite popular
combination.

------
merlinsbrain
[2017]

Marking it with the year is extremely relevant for me since I’ve been doing a
lot of reading on NixOS and was hoping this was a new article.

As it is, it’s an interesting recap of someone discovering Nix.

~~~
ianai
What is the significance between then and now for nix?

------
shawndellysse
I feel the need to plug my take on NixOS, but based on ArchLinux

[https://github.com/shawndellysse/effuvv](https://github.com/shawndellysse/effuvv)

NixOS is awesome, but it requires you to relearn all your sysadmin techniques;
this is great in the long run but not so great in the short run. effuvv tries
to be a solid middle-ground between traditional linux and functional system
management

------
kuznero
There is a follow-up post on haskell project structure in NixOS:
[http://www.kuznero.com/posts/nixos/haskell-project-
structure...](http://www.kuznero.com/posts/nixos/haskell-project-structure-in-
nixos.html)

