Comment by Baeocystin 4 days ago
The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".
> I think we've gotten used to development environments being a shitty experience to the point where it seems part and parcel of programming…
I have staunchly refused to allow this at my current employ, and I’ve been there long enough where I can steer this.
This isn’t acceptable and all it does is help introduce inconsistency and regressions.
I realize I am fortunate in that I can effect change at my job in this arena.
Well the short answer is: I defined the workflow/process for our team, everyone bought in, and new people don't really have a choice but to follow along.
The longer answer is, earlier in my career I ended up spending a not-insignificant amount of time helping people debug things, and about 70% of the time the issue was their local build environment. Everyone did it differently and it was very messy.
I only made a few "rules" to follow. 1.) Your local folder structure must mirror exactly the structure in our central repo. 2.) Must use relative paths, which works when you follow rule 1. 3.) No ad-hoc "new shiny things" without team buy-in. If it can be used locally only and won't affect the team obviously I don't care.
Does containerization get you most of the way there? I feel like containerization + one of the tools built on top of nix (e.g. devbox.json) should get teams close to 100% there, that's my goal.
One of the workflow I’m trying to practice is the idea of workspace. It can be done with virtual machines or containers on linux. As you can guess, it’s about one project per system. I don’t mind the redundancy as it brings me peace of mind when configuring the system or managing dependency.
Nix's core idea is wonderful, but I wish it could be redone from scratch. Why can't we just layer some Flatpaks that have source code in them or something?
But the whole thing seems like it's designed to express more powerful things than you can easily map to an app store style install/uninstall button, rather than solving the problem with the least powerful tools that give the user the highest level interface possible, and leave as much as possible for the computer to figure out.
Nix works extremely well _with_ Docker! That's what makes it so interesting.
That is not why neither Bazel or Buck was created.
Bazel is the bane of my existence. I have never seen such an anti distro tool that is so hostile against your system libraries.
They do hermetic builds so that it is viable at large scale via granular caching. They were made to make that work at those scales, with pretty much zero consideration for any external package managers or anything like that
The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be cleaned up, and things _are_ getting better.
The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.
This is how I feel about Nix.
I've given it a try and it's quite incredible how easy certain things are.
The problem is the Nix language and the developer experience are really rough.
There's a chance that Nix could figure this out or a competitor with Nix-like ideas could become mainstream. That's my hope anyway.
It would be a shame if the ideas behind Nix got dismissed because of the current issues with Nix.
It's basically, I refuse to learn how to containerize.
Just learn, use, promote best practices and stop forking the ecosystem _even_ further...
There, I got that off my chest.
As a heavy container user myself - I've been using containers since I needed to build my own 3.x kernel to test them - docker doesn't solve the reproducibility problem nix solves - IE, I can make a Dockerfile that does `RUN curl foo.com/install.sh` and who knows if that'll work ever again. Nix on the other hand doesn't allow you to do IO during builds[^0] only describe the effect of doing the IO.
[0]: Though apparently darwin (mac) doesn't support sandboxing by default, so you can bypass that but anyway
>who knows if that'll work ever again
Unless you restrict your nix files to specific channel revisions, which when I had to deal with it was poorly documented, and involved searching through specific channel commit hashes in a particularly opaque way, you also can't know that your nix derivations will ever work again.
A number of people on my field used nix as a way to make their research code repositories reproducible, and everything broke within around three years.
You can just store the actual container though. Which will reproduce the environment exactly, it's just not a guidebook on how it was built.
The value of most reproducibility at the Dockerfile is that we're actually agnostic to getting a byte-exact reproduction: what we want is the ability to record what was important and effect upgrades.
Containerizing an application is far easier than packaging an application for Nix - I think most avid Nix users would agree with that.
The reason why Nix users "refuse" to containerize is that Nix packages and their associated ecosystem come with a host of benefits that their containerized counterparts do not.
Nix handles containerization better than Docker does.
Here is a flake that builds a Go app and a Docker image for it (based on headless Chrome): https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0...
And here is how the image is built in CI: https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0...
here is a derivation that fetches https://www.usememos.com/ from source, changes the color palette, builds a docker image out of it and spins up a container that traefik exposes automatically: https://gist.github.com/knoopx/afde5e01389e3b8446f469c056e59...
1. Unbelievable layer reuse out of the box. Each Nix build output is placed in its own layer, including your binary (up to a max of 120 or so layers). Rebuilding the image will only result in the final layer changing, which minimizes work on image push.
2. Everything is pinned to nixpkgs, including dependencies. Anyone who builds this image will get the exact same versions (vs. apt-get update in a Dockerfile pulling a more recent version). It’s just sqlite in this case, but you can imagine how it would work with more dependencies.
3. It is trivial to build a “FROM scratch” image - in fact, that’s the default behavior in Nix, because Nix implicitly includes all runtime dependencies alongside your binary. This is less of a challenge with Go, but YMMV with other languages.
4. You can define your entrypoint script - or any other one-off script - in-line. Not a huge advantage, but still quite useful.
There is even an alternative pattern that allows you to reap these same benefits directly in your Dockerfile:
https://mitchellh.com/writing/nix-with-dockerfiles
Hope that helps.
Nix and containerization aren't drop-in replacements for each other.
You can use Nix to build containers. Containers on their own don't guarantee reproducibility, especially if the build process isn't static and pure ( how many times do we `sudo apt update` inside a Dockerfile )?
And not everything is going to be containerizable. That only works for most applications. What if we're trying to manage our cloud servers? That's where Nix really shines.
Do you really think that Nix developers don't know how to containerize applications? You think people are using Nix because they refuse to learn how to containerize, and therefore opt to learn a _much more_ difficult and arcane build process? The logic doesn't track there.
Huh? I use Nix to create containers. Nix is a programming language, a build tool, a package manager and an entire ecosystem of extremely powerful tools.
The entire reason why I use Nix in the first place is because it allows me to containerize with _better_ reproducibility than docker itself.
I do get where you're coming from though. It's not immediately clear that Nix can do all this stuff. Nix is a lot more than just "glorified weird package manager".
At its core, Nix is a way to specify dependencies in a mathematically sound manner. Once you have that pure dependency graph managed with Nix, you can start doing the _real_ fun stuff.
Like, you can containerize it. Or you can create a VM from it, or an ISO, or a NixOS distribution with _only_ that package installed.
Nix actually makes containerization _easier_, not harder. But yes, I empathize. Nix is a mess and it is difficult to understand, it will take a few more years before it is fully settled.
In the meantime? I'm going all-in on Nix (the philosophy, not necessarily any particular variant) because I really strongly believe this is the way forward.
Well, yeah.
Nix is attempting to be better than containerization.
Saying "improvements aren't necessary because we already have 'good-enough' technology" is a meaningful argument when the improvements aren't significant.
In my view, they are significant because Nix can be used to create a fully featured OS instead of just a VM.
> they are significant because Nix can be used to create a fully featured OS instead of just a VM
Look up Bootable Containers project by RedHat [0]. Fully featured OS built from a Containerfile, bootable on bare metal.
I agree that Nix design is much better than Docker, and has a bunch of features that OCI ecosystem doesn't (e.g. remote builds[1], partial downloading of the build tree, non-linear build process[2], nix store import/export, overlays, I/O isolation, much better composability), but "creating OS instead of VM" [did you mean container?] is not one of them.
[0] https://github.com/containers/bootc
[1] You can use DOCKER_HOST, and I'm happy that this option is there, but Nix does it better.
[2] Perhaps with BuildKit it's no longer true, I haven't checked what happens if you have multi-staged build with one stage depending on multiple previous ones (which are otherwise unconnected). I think Earthly can parallelize this scenario https://earthly.dev/
Yes buildkit can do this. You can also use buildkit to create a bootable VM, just that nobody is doing it. You can use estargz to fetch just the pieces you need from a dependency rather than the entire depdency as well. Really all of the things you mentioned should be possible with buildkit, just that the focus of most things is Dockerfile which has much more limited functionality (though some of the things mentioned above still apply to Dockerfile).
I think that's a bit reductive, but I get the intent. A lot of people see systemic problems in their development and turn to tools to reduce the cognitive load, busywork, or just otherwise automate a solution. For example "we always argue over formatting" -> use an automated formatter. That makes total sense as long as managing/interacting with the tool is less work, not just different work.
With Nix I still think it's a net positive, but the "different kind of work" side of the equation is pretty large. That's why we're building Flox [1]. The imperative user interface of a package manager (flox install, flox search, etc) that builds out a declaratively-configured, reproducible, cross-platform developer environment. I really think it nails the user experience by keeping that "different work" side of the equation small, and (I hope) just gets out of your way.
[1]: https://flox.dev
Quickly skimmed through the Flox site and it looks like it’s based on Nix. The problem with the competitor https://www.jetify.com/devbox and most likely in Flox is that Nix makes trivial environment setup really easy but when you need something more complex it falls apart because the Nix packages are often unmaintained and simply broken.
I just started using Flox last weekend and so far it has been quite nice experience. There are two things I don't like, though:
1) The Homebrew package is a cask that installs also Nix. While I like Flox, I don't want my systems to be married to it. Yes, I know about install option with "generic Nix", but I'm using Homebrew with Brewfile both in macOS and Linux, and I would like the Homebrew package to be just Flox.
2) Documentation is OK for getting started, but not for anything more than that. There are nice manifest.toml examples for many use cases in floxenvs[1] but you need to find those first. Also I'm not sure how I feel about inline shell scripts in toml. While it works, separate files would be easier to handle, at least for me.
Nix currently has the most packages of any distribution, see https://repology.org/
The model of having packages on Github with pull requests scales very well.
Therefore, you could argue that people are getting things done with Nix.
How many of them actually work though? If you end up having to go fix upstream packages then having a tool manage your environment is not useful since you still have to understand the domain.
With Nix I usually ended up in a situation where I had to both figure out how to configure my environment _and_ fix the upstream Nix packages. At that point it’s just easier to stick to Homebrew and some custom shell scripts.
> Nix currently has the most packages of any distribution, see https://repology.org/
This is a meaningless point. Different distros split packages differently.
While I agree that it’s somewhat difficult to compare. Especially as node and python packages are separately packaged in Nix.
However it is clear that the Nix folks are quite productive with maintaining packages. So that statement is judgemental, as it implies that all those packages are not ‘the right things to get done’.
No it’s very much meaningful. for every new ecosystem it’s immediately graded based on whether it has the critical mass of adoption. The build and release system is great, what I actually wish for is nixpkgs to offer debs and rpms to ensure that maintainers flock here
I tend to agree. I also think both sides need to learn to better appreciate the other.
Without people getting shit done with the tools we’ve built, there would be no demand for better tools and no need to write them.
Without better tools, the things we can get done are limited. Better tooling is an exponent to our productivity. The things we can accomplish today would have been nearly unimaginable nearly thirty years ago.
> Better tooling is an exponent to our productivity
Nix & NixOS have made me much more productive. Maintaining a desktop is effortless. If something breaks, I can simply reboot to a previous installation. I can also try software without installing, and develop parallel projects relying on dependencies that would be mutually incompatible in a regular imperative package manager.
But I recognize that if you need to do something slightly unusual, documentation is incomplete and scattered. For simple things, my contrarian view is that Nix is not hard at all. The subset of Nix I use can be learned in a couple of hours. I think the trick is to avoid getting sucked into packaging complex software with messy build systems. If the stack you use is well packaged in NixPkgs, it's a joy to use. If it's not, it's better to stay away.
I first heard of Nix a few years ago from someone who fell firmly into the camp of "the tools are the interesting part." Despite my reservations, perhaps because I didn't want my opinion of the person to lead me away from something useful, I started to mess with it. After about 30 minutes I decided it was not for me and have not touched it since.
I do keep an eye on Nix-related stories to get a sense of whether or not I should change that stance. So far, nothing has led me to change it.
I enjoy writing tools.
How do you feel about Kubernetes?
It would be good to have some interesting tasks to do?
I think the tools should do also much of the work. I actually prefer batch systems that are a simple execution of a program against a dump which are just process all the data and generate data with the new states than a networked online system that breaks all the time and due to DNS
Micro services keep me awake but a simple CSV processing I can fix in my own time.
Your veiled implication that Nix and NixOS aren't about "getting things done" is, I think, more than a little unfair. I'm using multiple programming languages at work. Each one of them has its own dependency manager that does basically the same job as the other ones. In Python it's Poetry, in Ruby it's Bundler, in JavaScript it's npm/yarn, in PHP it's Composer, etc. A lot of projects require extra setup steps outside of the dependency manager. It's not a good experience that lets you get up and running quickly. And my situation with scripting languages isn't the worst case: God help you if you have dependencies between projects in AOT compiled languages that use different dependency managers.
Of course, the standard answer is to spin up a ton of Docker containers. Docker works, but it looks to me like a local optimum rather than a truly painless solution. It sucks as a build system, and Dockerfiles not being reproducible is the default outcome that needs significant extra care to avoid (how many times have you seen apt update or some equivalent in one)? Besides, why should I have to worry about a whole another OS inside my main OS, with potentially different tooling and conventions, when what I really want is just specific versions of a couple of tools?
I think we've gotten used to development environments being a shitty experience to the point where it seems part and parcel of programming, but when you take step back, it's apparent that the situation causes a lot of frustration and wastes a lot of time. To me, Nix's combination of package manager and reproducible build system looks like one of the most credible ways out. NixOS' declarative configuration and rollbacks are nice side benefits too, for server admins and newbies respectively. Nix just needs a lot more polish. I'm not about to introduce a tool where the most common workflow is still considered experimental. For now, I'll keep using Docker, but I watch Nix with interest and can't wait until its UX matures.
EDIT: Removed claim that Bazel and Buck's creation was motivated by multi-language support. Looks like the main motivations were speed and reproducibility.