Comment by pkkm | Hacker News Reader

Comment by pkkm | Hacker News Reader

Parent Full thread

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.

> 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.

What's been your strategy for doing this

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.

> Your local folder structure must mirror exactly the structure in our central repo

Do you use a monorepo at work, or do you have like a repo for a 'local dev environment' or something like that?

Agree completely. I used to allow every programmer to set up their own dev environment. Inevitably we’d have things that worked for one person but not another, and low confidence in deploying to production.

Eventually I forced everyone to work with a controlled dev environment on a remote server. They can work over ssh with command line tools or VSCode. Dev environments get rigorously maintained to mirror production. I got some grumbling about latency (everyone works remotely from around the world), but that turns out to present much less friction than the almost-daily debugging sessions and dealing with MacOS vs Windows vs Linux inconsistencies.

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.

I use Nix and agree with most of what you said, except the main value proposition of docker-on-dev-machine is not convenience, but approximation of production

Nix works extremely well _with_ Docker! That's what makes it so interesting.

https://www.youtube.com/watch?v=0uixRE8xlbY

That is not why neither Bazel or Buck was created.

It's not? I recall reading that coping with a variety of languages was one of the main motivations, but do correct me if I'm wrong and you have a citation.

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

Hm, I did some searching. Bazel's FAQ mentions multi-language support prominently, but only suggests speed and reliability as the initial motivations. I'll edit my post.

Yeah that is a thing for sure, was just commenting on why it 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.

That's the whole point, you can't rely on systems for hermetic builds.

Bazel was built for reproducible builds. Meaning it literally exists to compile stuff without using your rando sus system libraries.

Naturally the solution is to use a complete different OS stack. /s

nix is just a package manager, you can install it on other distros, even on macOS. nixOS is the distro based on nix the package manager, hope this helps.

Reply on news.ycombinator.com