I use Nix and it's awesome, but still in early adopter territory. It works wonderfully if you really value reproducible builds and are willing to put some effort in the initial setup, but it's still a bit fiddly and documentation is nearly non-existent. If you have the time and motivation to learn about it up-front and get it set up it pays off, but I wouldn't recommend it to beginners just trying to learn Haskell.
I couldn't disagree more. Nix doesn't make development easier. In fact, it substantially complicates development to ease open source delivery and client dependency management. These are things that are of questionable value to the Haskell or product dev ecosystem, as people far more often prefer fully static (admittedly large) binaries anyways.
And, Nix doesn't work well with existing tools like intero, it requires troubleshooting to get working with ghc. You can pick either stack or cabal and both sort of support Nix, but in every case some tooling will not quite work right.
Further, if you're not doing 100% open development, Nix's delivery story is also complicated. It's further challenged for projects using private docker or GitHub repos, where in many cases there is simply no support in Nix.
No one does Haskell newbies any favors by suggesting they learn a whole new package expression language and toolchain (that they will be interacting with deeply and constantly) in addition to a language that is full of fundamentally novel concepts and a vast breadth of new libraries, techniques, and a distributed documentation style.
Please. Stop recommending Nix to new Haskell users until at least the new porcelain commands are shipped.
I use nix in production, and I love it. It's just as good in practice as it is in theory.
I think the problem is that really using nix involves learning a new language. And it's a weird lazy functional language at that. So yeah, the Haskell folk adopt it readily enough, but everyone else has a high barrier to get over. The only people that do it are the ones that have really wrestled with the problem of dependencies and can see how well nix solves it.
Something to be aware of for Haskell: Nix's Haskell infrastructure has gone through a big breaking change recently. It's settled down now, and the new system (AKA "haskell NG") is much nicer, but all of the "stable" releases are using the old system, and a lot of blog posts, etc. online are now out of date.
I have been avoiding nix for a while since I had a bad time with it several years ago, however recently used it for a small Haskell/Latex environment for literal programming and found it worked really well. I’m probably going to invest time into learning it now, as the online docs seem to have gotten better.
I've tried this out a few days ago. I have some basic theoretical Haskell knowledge, but not much practical experience. However I do have some significant Nix experience.
Ended up not even going through the beginner tutorial, as the installer/scaffold process required me to do things that I didn't like:
- forced scaffolding of projects with some quite blackboxy generated shell scripts inside
- use of nix, yet requiring me to install 'make' and 'direnv' system-wide (why? just let me use a shell.nix)
- required me to use cachix.org as a system-wide nix substituter, which I don't want to do for security reasons (just allow me to build everything myself)
All in all this looked promising, but ended up being too magical for my taste. I'd like to be able to start using IHP 'from scratch' instead - with my own Cabal/Nix/Bazel build machinery. This is a critical requirement for libraries/frameworks that I use.
Your mileage may vary though - if you're okay with RoR-like scaffolding and blackboxness, then you might feel at home here, and at least you get a nicely typed language in return.
I agree with what you're saying. It probably took me about 2 weeks to build my first NixOS desktop about a year ago. Now I manage everything in a single repo, including all my dotfiles, all via nix. It works great. But there was a very steep learning curve.
After that experience, I'd actually hesitate to use NixOS in a production environment. The main problem is Nix and the library functions themselves are incredibly obtuse. It also doesn't help that it's a dynamic functional language, so everything just looks like magic when you're first using it. I think most engineers would really struggle with it. I'd be more comfortable introducing Haskell - I think it's easier to learn and understand!
Perhaps in contrast to most people's experiences, I haven't found Nix hard to learn. I think it really helps if you have learned Haskell before. Nix (the language) is really a simple functional programming language, but Nix relies quite heavily on functional programming concepts like laziness, fixed points, etc. A lot of things are underdocumented, but if you understand the Nix language well, it isn't hard to look up definitions in nixpkgs. I can understand that it is all very alien and overwhelming if you do not have a grounding in functional programming.
The primary issue for me has been that Nix is a very deep rabbit hole. You can spend enormous amounts of time on making your configuration more functional and declarative. Pretty much like you can spend enormous amounts of time on customizing an Emacs configuration. It's hard to strike a balance. And outside declaratively defined infrastructure (servers), it's probably not really worth it. I could almost fully reproduce my NixOS system (there is always some mutable state left) with a single command. But takes many months of effort to get to that point. On the other hand, I can set up a fresh macOS or Fedora Silverblue systems with all my customizations in 1 or 2 hours and have to do that maybe once of twice a year? So, ¯\_(?)_/¯.
I think the balance is different when you manage a lot of servers and most servers can be defined as a function with a small number of varying parameters.
The other part of the rabbit hole is that software breaks frequently in Nix. Upstreams do not really develop things under the assumption of a non-FHS, immutable system. So, you were going to work on something, but before you know it is 30 minutes later because you ended up fixing some package you need and that broke. Similarly, you'll end up packaging a lot of stuff and spending quite some time making it fit the Nix mold (looking at you Python packages that mutate in-place, sigh).
I love Nix as a principle -- it's declarative, immutable, pure, reproducible. But in practice, you can reap many of the same benefits from impure, inferior alternatives, with far less work. Yes, Docker is an ugly duck compared to Nix, but it brings 90% of the reproducibility benefits and probably everyone on your team can be up and running in hours. Rust's cargo doesn't allow you to specify every non-Rust dependency exactly, but with a Cargo.lock file you can make most of your build reproducible. NixOS is a clean, immutable, declarative system, but other systems offer a subset of its features, such as atomic upgrades/rollbacks, immutable root, and isolated applications (e.g. Fedora SilverBlue + Flatpaks, Fedora IoT, macOS). These alternatives are far more familiar and easier to work with. You can get most (but not all) of the benefits of NixOS with far less work.
Yes! The Haskell community has been using Nix to great effect and I would like to see other programmers catch on as well. Here is a great talk about using Nix targeted at Python programmers: http://pyvideo.org/video/3036/rethinking-packaging-developme...
In addition to Nix, there is also a newer project: GNU Guix. Guix is built on top of Nix but replaces the custom package configuration language with Scheme, among other differences. https://gnu.org/software/guix/
When package management is solved at the system level, our deployment situation becomes a whole lot better. I used to do a lot of Ruby programming. Wrestling with RVM and bundler was a real pain, especially since bundler was incapable of helping me with the non-Ruby software that I needed as well like libmysqlclient, imagemagick, etc. Using Nix/Guix, you can throw out hacky RVM (that overrides bash built-ins like cd!) and simply use a profile that has the right Ruby version.
I don't use Nix with Haskell myself yet, because I haven't been doing much Haskelling recently. But I do use it with Python and it's really excellent to use once you start to "get it." Skimming this guide, it seems to do a nice job of explaining Nix as applied to Haskell development[0]. And I'm sure there are many other resources, since it seems to have some traction in that community. I don't know much about the other options you mentioned, but one of the really nice things about Nix is that it's language-independent, which makes it just as easy to express Haskell package dependencies as it is to express any arbitrary dependency (e.g. a foreign library you're linking against).
I, too, have no desire to put so much work into having a working system (but I guess, there’s no way around nix for me, if I want to use haskell and ghcjs). Unfortunately from my own recent personal experience it does indeed have a steep learning curve .
I really like the general idea of nix, I think it’s going in the right direction and I am very grateful for all the people doing amazing work there and I wanted to give it a try for a long time, now.
But my recent experience with nix on MacOs has mostly just been incredibly frustrating. I started using nix one or two weeks ago, because I needed it for a project with haskell-miso (which I very much like, by the way).
As long as I just stuck to using the default.nix provided by Miso, everything worked fine, more or less, but as soon as I tried to go beyond that to customize things for the needs of my own project, the problems started to accumulate.
I needed to google for and apply manual fixes for some very basic things, because nix did not play well with neither macOS Catalina (nix needs access to /nix) nor with fish.
Some haskell packages I need like constructible were broken in the default channel and I had no idea how to fix those packages. In the end I ended up switching to a “stable” version. I do not understand why nixpgs-unstable is the default channel, by the way.
Sometimes things seem easy in some guides and I thought I understood them, but then when I tried them they just won’t work. For example I was hoping that
nix-shell -p 'haskell.packages.ghcjs.ghcWithPackages (pkgs: with pkgs; [ miso ])’
would give me a shell with the ghcjs compiler and the package miso, but that resulted in an error (after waiting for the result for quite some time and a lot of text scrolling by).
I tried following guides and didn’t try to do anything especially crazy, but somehow I ended up fucking up my haskell build environment so much, that I couldn’t do anything Haskell-related anymore. Still don’t how I managed to do that.
I tried rolling things back through
nix-env -G 1
but that didn’t work. Somehow the only think that helped me was deleting everything nix-related and trying again. I then switched away from the unstable channel in the very beginning and now things seem to somewhat work, more or less.
When I was 15 years younger I really enjoyed playing around with the configuration of my computer, trying different window managers and editors etc., but nowadays I have work I care about and limited time and I want my computer to just work and not get in the way. Nix really, really got in the way. It’s been incredibly frustrating the last few days, when I wanted to work on my project, but spent several days fighting with nix instead.
Sorry for the rant, again, I very much like the project and I really hope it succeeds, I just wanted to share my own experience with it, as a beginner.
Actually, unlike most DSLs, the nix language itself is pretty great and can be learned in an afternoon by any competent programmer, no Haskell background needed.
The problem absolutely is complexity, and there is a lot of stuff you need to grok to be able to use nix productively in anger and sadly that includes a lot of stuff that really ought to be much more straightforward.
Also, IMO you don't do anyone a favor by recommending they try Guix-SD over NixOS unless you also make it pretty clear that Guix is quite fringe even compared to Nix. For example Nix can and is being used for Real Work by well known companies. It as a steep learning curve but also, for certain tasks, an enormous payoff that justifies this effort.
I have a very minimal nix.configuration, write very small shell.nix files, and try to only use things I know or understand. So I’m definitely only using 1% of Nix right now but I’m comfortable with it!
Edit: I should clarify Nix is the build tool at work for Haskell and some of my colleagues are contributors so I know I can get help if stuck. I’m a noob though.
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.
I love nix and have contributed quite a few packages to the nix repository, and I will vouch that it’s anything but easy. I have a background in Haskell which makes it more familiar, but even the syntax is counterintuitive to newcomers.
I found out about guix after already investing in nix. Looks great, and better in many ways, but I'm more familiar with Haskell syntax than lisp, and my understanding is that the nix ecosystem is far more developed.
idk, as a part-time Haskeller, I think Nix-the-language kinda sucks (tho not enough for me to not use nix). IMO the big huge thing is really inconsistent nixpkgs docs; compare linkFarm and symlinkJoin's docs, for example. I wish there were some way of getting nice autogenerated docs, but I don't think we're gonna get there without either adding some kind of type system or having a pretty strong review requirement that's actually enforced, and doing that for a year or more...
One thing that irks me about the current Haskell ecosystem is that it seems to be going all-in on Nix. Nix is interesting, but I can't think of another programming language where the only way to get a reasonable development environment is to run a particular Linux distribution.
(I know that you can install nix as a package manager on OS X and other Linux flavours, but at least on OS X, packages don't work all that reliably. The enormous disk space requirements are also an issue when using a laptop.)
reply