4 ms·

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 t

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-should-give-it-try.html http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-sho... AMA

trishume 11y ago
Can you give an example of what you have tried to do in Nix that you couldn't do well due to lack of power? I imagine it is something rather fancy since for most configuration tasks Nix is significantly more powerful than other config file languages. Number 2 sounds like a legit bug rather than an inherent problem with the design. If you haven't already maybe you can file an issue on Github and it could get the timeouts to apply correctly.
- danharaj 11y ago
  Hm, i don't think i have a specific example of the first issue that isn't under NDA. In the abstract, "higher order" derivations, that is derivations that produce other derivations which in turn get built are a bit cumbersome to work with. Nix is perfectly capable of expressing complex dependencies which just invites a person to push it to its limits. The limits are purely practical. You can go as far with nix as you are patient with working in a barebones language. Number 2 is probably a bug, yea. It's certainly not a design flaw. It's just a wart. Unfortunately, even though nix has a strong community of great contributors, it's a very ambitious project and so warts and rough edges are part and parcel of the nix experience.
jonaf 11y ago
Out of curiosity, how do you handle deployment of databases on nixOS? I'm curious how others run stateful services on nix
- danharaj 11y ago
  So at Obsidian Systems[1]*, my current shop, we deploy by building the entire system image and then transferring it to the server, and then activating the server. The NixOS master config file lets you specify global services like a PostgreSQL server and its initialization script. [1] https://obsidian.systems/ https://obsidian.systems/
- davexunit 11y ago
  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.

trishume 11y ago

Can you give an example of what you have tried to do in Nix that you couldn't do well due to lack of power? I imagine it is something rather fancy since for most configuration tasks Nix is significantly more powerful than other config file languages. Number 2 sounds like a legit bug rather than an inherent problem with the design. If you haven't already maybe you can file an issue on Github and it could get the timeouts to apply correctly.

danharaj 11y ago
Hm, i don't think i have a specific example of the first issue that isn't under NDA. In the abstract, "higher order" derivations, that is derivations that produce other derivations which in turn get built are a bit cumbersome to work with. Nix is perfectly capable of expressing complex dependencies which just invites a person to push it to its limits. The limits are purely practical. You can go as far with nix as you are patient with working in a barebones language. Number 2 is probably a bug, yea. It's certainly not a design flaw. It's just a wart. Unfortunately, even though nix has a strong community of great contributors, it's a very ambitious project and so warts and rough edges are part and parcel of the nix experience.

jonaf 11y ago

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

danharaj 11y ago
So at Obsidian Systems[1]*, my current shop, we deploy by building the entire system image and then transferring it to the server, and then activating the server. The NixOS master config file lets you specify global services like a PostgreSQL server and its initialization script. [1] https://obsidian.systems/ https://obsidian.systems/
davexunit 11y ago
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.