4 ms·
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 a
by pkkm 2y ago
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.
- eacapeisfutuile 2y agoThat is not why neither Bazel or Buck was created.
- pkkm 2y agoIt'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.
- eacapeisfutuile 2y agoThey 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
- pkkm 2y agoHm, 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.
- eacapeisfutuile 2y agoYeah that is a thing for sure, was just commenting on why it was created :)
- SuperSandro2000 2y agoBazel is the bane of my existence. I have never seen such an anti distro tool that is so hostile against your system libraries.
- eddd-ddde 2y agoThat's the whole point, you can't rely on systems for hermetic builds.
- ycombinatrix 2y agoBazel was built for reproducible builds. Meaning it literally exists to compile stuff without using your rando sus system libraries.
- dgfitz 2y ago> 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.
- nbbaier 2y agoWhat's been your strategy for doing this
- dgfitz 2y agoWell 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.
- catlover76 2y agoDoes 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.
- johntash 2y ago> 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?
- 2y ago
- oDot 2y agoI 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
- azeirah 2y agoNix works extremely well _with_ Docker! That's what makes it so interesting. https://www.youtube.com/watch?v=0uixRE8xlbY https://www.youtube.com/watch?v=0uixRE8xlbY
- pjmlp 2y agoNaturally the solution is to use a complete different OS stack. /s
- jdmg94 2y agonix 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.
- deleted 2y ago[deleted]
- skydhash 2y agoOne 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.
- eternityforest 2y agoNix'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.