Super Colliding Nix Stores: Nix Flakes for Millions of Developers

I think the best part about Nix is that it makes it super easy to get software into your development environment. This layered store is a pretty cool setup to make that efficient for Replit.<p>Not sure how if Nix&#x2F;Replit has the program you’re looking for? Or what package name to use to actually get the program you want? Check out my cli search tool:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;peterldowns&#x2F;nix-search-cli">https:&#x2F;&#x2F;github.com&#x2F;peterldowns&#x2F;nix-search-cli</a><p>Edit: I can’t help myself from ranting, it’s insane that I had to write this tool. Speaks to the lack of user focus in the Nix community. Even the blog post here doesn’t mention how to actually find packages to install!<p>What good is a package manager that makes finding packages difficult? Who should be expected to tolerate such a thing?

Dang this is cool! I get why replit went so heavy on nix but I also feel like it must have a cost for them — nix is hard to learn, especially for folks new to development which I know makes up a lot of replits customer base.<p>We built a solution to the same problem with a similar approach[1], but that just snapshots any old files instead of doing nix derivations. Nix couples the build process to the content-addressability of the output, which works great if you want to put all the effort in to deterministic builds. We just read files like git does which works great for non-deterministic processes like npm install (tragically).<p>I like the idea of the Big Disk style of attaching a content addressable cache, but in our experiments we still found the network latency to the attached disk too high when reading file by file, like when booting a node app, so we’re caching a much smaller amount on a local SSD for each prod server. Maybe replit isn’t as sensitive to read perf from the cache layer, or they have fancy local per-node read through caching within the overlay setup? Regardless, cool!!<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;gadget-inc&#x2F;dateilager">https:&#x2F;&#x2F;github.com&#x2F;gadget-inc&#x2F;dateilager</a>

I love Nix as a package manager, and flakes are awesome for setting up environments. I wish it had more affordances for being a proper build system. If only there were a Buck2 and Nix hybrid.

Nix Flakes are deemed experimental and explicitly not recommended in prod by the Nix project, afaict. Despite these warnings it’s widely used, but breakage is very much a possibility because it hasn’t gone through the Nix RFC process.

I don&#x27;t get how people find nix useful. Setting up a python environment, for example, is a total nightmare. Nix lang itself seems completely unnecessary. Guix is using scheme, which I assume people would be more incentivized to learn just because it&#x27;s a general programming language. So why is nix winning?

So do they share their implementation of overlaying stores somewhere? It would be a huge benefit for the community to have it open source and available for being used in countless other use cases.

A less painful alternative to dancing around the issue is just to use the filesystem itself as a global database.

But oh my, the security implications. Nix is great, but there&#x27;s no chain of trust on where these packages come from. Did we learn nothing from &#x27;left_pad&#x27;?

Nix is solving the wrong problems, and I&#x27;m dismayed that it is being adopted more and more to solve those wrong problems. The very concept of a &quot;development environment&quot; is indicative of broken build systems. Ecosystems like python are trying desperately to tame the insanity using venvs, while ecosystems like rust were built correctly from the start with Cargo. Neither of these benefits in the least way from Nix or the most popular alternative, Docker (except that both end up falling victim to the insanity of other ecosystems when FFI comes into play).<p>What Nix could have been was a global un-fscked dependency manager, a la Portage but with Nix&#x27;s special sauce for local environments -- thereby working around fundamentally and permanently broken ecosystems like C, which would be useful even in the FFI case. But somehow it never got around to actually managing dependencies. By failing to manage dependencies (by pretending that versioning doesn&#x27;t exist, and supporting only exact software sets), Nix only re-entrenches the same bad behavior and broken systems which it should have been replacing: i.e., <i>encouraging</i> &quot;works-on-my-system&quot; build environments, by making them part of mandatory collaboration workflows.<p>So, soon: Encounter a bug because the build depends on the environment in some inappropriate, insane way? Then it&#x27;s your own fault for not adhering to the approved Nix build instructions which would set up a system which doesn&#x27;t exhibit that bug.