
Deploying a Haskell Web Service with Nix - yakshaving_jgt
http://jezenthomas.com/deploying-a-haskell-web-service-with-nix/
======
SwellJoe
NixOS (or Guix) seems like an ideal platform for building service-based
architectures. I don't understand why it's not more popular. CoreOS seems to
be extremely popular in that space, despite working against a somewhat crappy
package manager (portage from Gentoo) and with all of the declarative stuff
slapped on top in a quite heavy-handed way. With CoreOS, you roll entirely new
images whenever you have a change to deploy. So, the goals are the same, but
the mechanisms are so very different as to make them look like they're solving
different problems. I'm pretty sure I prefer the way NixOS is going about it.

That said, I've not used either in production. But, Nix was the first time
I've looked at a new package manager and thought, "OK, someone finally
improved on RPM/yum or deb/apt." Most of the time, I look at new package
managers and just find myself running down a list of all of the ways they've
failed to even replicate the power/flexibility/reliability of those now-
ancient package managers, and usually without any really good reason. It's a
cool side effect of a superior package manager that so much other stuff comes
easily or automatically.

Anyway, this is a really cool idea, and something I want to look into more.
You get so much of the "declarative and predictable" elements you want in a
service-based architecture for free with Nix, while so many other solutions
are bolted on clumsily.

~~~
teh
We're using Nix in production. It has some polish issues but even in its
unpolished state Nix is adding a lot of value for us.

I meet people that have all kinds of familiar issues with puppet, chef etc. We
used to have those problems and we just don't have any more.

~~~
SwellJoe
That's exactly what I think is so neat about it. puppet, chef, ansible, are
all really cool, and they manage to bolt a declarative and atomic looking
facade onto something that is decidedly not declarative or atomic (a regular
old operating system). But, NixOS hits the problem in the gut. It seems like
everything that is hard about the problem disappears when your entire OS is
built from the ground up to be declarative and atomic.

It's pretty neat, and once I get my current projects squared away, I want to
spend some time with NixOS, and maybe even get involved. It's just such a nice
idea, and doesn't make me feel queasy the way so many of the bolted on
solutions do.

~~~
jonaf
A minor correction as a courtesy to other readers: puppet, chef, etc are not
atomic. They can usually be considered thread safe across processes, if for
some reason you run two simultaneously, but that is not a guarantee. Their
changes are visible while they are executing on the system, so to other
unrelated processes, they are not atomic.

Nix is atomic.

~~~
SwellJoe
Not so much a correction...I think saying it is "a declarative and atomic
looking facade" implies it is not actually that, even though it might look
like it, doesn't it? But, perhaps it is a worthwhile clarification.

------
totalart9000
>[...] taking care to change ~/.zshrc to reflect the “run commands” file of
your shell if necessary

Huh, I've been wondering what the rc part of config files actually meant. The
only thing I could come up with previously was "resource" file, which didn't
make much sense but I never looked it up so whenever I deal with rc files, I
think of them as resource files. Now I know what it actually means and can
begin thinking of them as such.

------
nalllar
Link seems to be dead. 404.

Oddly, it works without the final '/'.

[http://jezenthomas.com/deploying-a-haskell-web-service-
with-...](http://jezenthomas.com/deploying-a-haskell-web-service-with-nix)

~~~
yakshaving_jgt
Sorry for the downtime. I noticed GitHub have bumped the Jekyll version on GH
Pages, so now all my links are broken from the outside. I've fixed this one;
now to handle all the others!

------
danharaj
I'm a Haskell contractor who currently works with a tech stack that looks like
PostgreSQL, Haskell (backend), Haskell (frontend), and Nix. Stuff gets
deployed to AWS.

things i hate about nix:

1\. The nix language isn't haskell. It's a very spartan functional programming
language. errors can be unhelpful and it is difficult to find thorough
documentation. There's not much sugar and it has few abstraction facilities
beyond higher order functions (like ML modules or Haskell type classes). In
order to grok nix, I recommend reading the nix manual[1] thoroughly and this
series of blog posts [2]. Honestly though nix would be much more powerful if
it were embedded in a full fledged functional language instead of trying to
focus on just package description. i am many orders of magnitude less
efficient at writing nix as i am haskell. guix looks interesting but i haven't
tried it seriously: check it out too.

2\. the caching system is a little boned. if a cache goes down, the builder
will wait forever to get the metadata from the server instead of ignoring it.
there is a timeout setting but it only applies to downloading the actual
binaries, not the .narinfo files. the workaround is to disable binary caches
for that invocation. it is an annoyance since i often work on projects with
flaky cache servers.

things i like about nix:

1\. i haven't fucked up my computer with NixOS yet. upgrading everything Just
Works. If it doesn't Just Work, reverting Just Works. You have to go rather
far out of your way to put a NixOS system in an inconsistent state. I might be
a somewhat reckless user, but i used to put my Ubuntu installations in
inconsistent states regularly.

2\. i can create a good sandboxed environment for any project with relatively
little effort. it doesn't matter how many languages or arcane dependencies
there are. there are no subtle bugs caused by interfering components: if
there's interference it's a build error; if there isn't, you're good.

3\. if you've used a build system in anger and you can only come up with two
complaints and neither of them are "it has trouble building the thing", then
you've found a good build system. i've never had to worry about dependencies,
reproducible builds, sharing binaries with colleagues or anything. in spite of
all the warts of the language and the byzantine user experience, by god it
works.

[1] [http://nixos.org/nix/manual/](http://nixos.org/nix/manual/) [2]
[http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-
sho...](http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-should-give-
it-try.html)

AMA

~~~
jonaf
Out of curiosity, how do you handle deployment of databases on nixOS? I'm
curious how others run stateful services on nix

~~~
davexunit
I can't speak for NixOS specifically, but in GuixSD (a closely related
project) this is handled at the service layer, an I imagine the same must be
true for NixOS. The OS declaration specifies that, for example, the PostgreSQL
daemon should be running with a specific configuration and the init system
will run it when the system is instantiated. Your database runs as normal, and
you would back up your state as normal. Functional configuration management
provides an extremely clean separation of stateless from the stateful.

