Disclaimer: I work at Amutable but not on tine (though we did discuss this internally a fair bit, as you might expect).

Nix does have a similar model in some respects (in particular the idea of input-hashed build graphs) and so solves a lot of similar problems but there were a few important factors that made us not go with Nix (or NixOS) and instead go with Buck2.

As the blog post mentions, the ability to build directly from a wide variety of upstream distribution artefacts and maintain temporary deltas was incredibly important to us. Our team has a lot of old-school packaging experience (I've done packaging for (open)SUSE for over a decade now and we have former and current Fedora, RHEL, Ubuntu, and Debian packaging folks with even longer histories) and our view is that distributions do a lot of thankless and incredibly valuable work and the most painful part of maintaining a distribution is the deltas you have to maintain forever after you've hard-forked packages or repackaged them. Buck2 allows us to create models for these concepts (which are in tine) without needing to boil the ocean repackaging upstream packages. But Daan and Martin are far better equipped to get into the weeds on this topic.

On the more general topic of why not use NixOS, as discussed in one of our other recent blog posts[1] we are make heavy use of sysexts and the /nix/store combined with the general linking model of NixOS (while very technically impressive) does not play particularly well with that model. I should also mention that we have a NixOS guy on our team too so you'd better believe NixOS came up in conversation. :D

[1]: https://amutable.com/blog/it-starts-upstream-kernel#image-ba...