Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
bdwgc
The Boehm-Demers-Weiser conservative C/C++ Garbage Collector (bdwgc, also known as bdw-gc, boehm-gc, libgc)
-
nixos-flake-example
This is a demo NixOS config, with optional flakes support. Along with notes on why flakes is useful and worth adopting.
-
There are noble goals to this project to rewriting Nix to improve performance. The reasons feel valid. However I would suggest thinking about this a bit more deeply:
* Nix itself has problems of compatibility with Nix! Let me explain...recently NixOS 21.11 released. It still comes packaged with Nix 2.3.16 instead of Nix 2.4 because of incompatibility issues. When the Nix project itself is not able to deliver backwards compatibility I feel uncertain that Tvix might be able to deliver their promise of full compatibility with all the deep architectural changes it plans. Nix does not have a formal specification: Nix is what its C/C++ implementation says. Nix also has deep architectural changes planned going ahead. So Tvix will need to re-architect Nix keeping in mind (and keeping up) with the future changes that are coming. It's going to be tough to build this "alternative" implementation. Users are going to run into weird compatibility issues, not have the patience to resolve them and then just go back to the original Nix implementation.
* A rewrite to a popular project will find it difficult to succeed. There is simply too much momentum in the parent Nix implementation (I'm not talking about the package definitions here) that very few people are likely to adopt this rewrite. This is because most people might not really need the speedup. However, it's possible that the pain around slow evaluation runs so deep that other companies might adopt this too. I don't know enough here.
* The rewrite needs to offer more reason to shift. Right now this rewrite seems to be mainly about performance. There is also a proposal to be able to integrate with GNU Guile. To me this is just avoiding one untyped language (Nix) to replace with another slightly better untyped language (Guile Scheme) (GNU Guix uses Guile also AFAIK). What about introducing typing? https://github.com/tweag/nickel is an interesting project and it would be great to have a system like Nix with optional typing to make writing the derivations more robust. What about rewriting in a safe programming language (e.g. Rust or a GC-ed language)? These things would be likely to excite would-be-contributors and would make your rewrite viable. In other words, the rewrite needs to offer more than just the promise of performance.
Perhaps I have not understood the project goals fully. Maybe the project is all about just being able to leverage the Nix package definitions but have a totally different implementation to instantiate them? But the issue here is that nix-the-language is very intimately tied up with the nix-the-platform and the rewritten implementation will still need to really be extremely compatible to capture all the implicit assumptions in nixpkgs.
Once again, improving nix through a rewrite is a noble goal. It's a tough problem and it would be awesome if the project succeeds!
I have obviously not thought about this as much as you guys and would love to learn how you wish to tackle some of these problems. Maybe some of these issues are not as big as them seem??
> superior to the array-backed implementation in upstream nix.
I fail to see how that is a performance experiment when it does not mention performance at all.
The post also mentions issues with the general Nix design and a desire to modernize it, which I am unqualified to comment for, but seems a worthwhile endeavor in and of itself. I do hope that they won't end up writing a new evaluator for the Nix language without a proper understanding of what makes the current one slow and a clear plan not to repeat its mistakes, or it risks being just as slow.
[1] : https://github.com/NixOS/nix/issues/2652
As sibling comments mention, this would struggle with edge-cases, and require too much buy-in from packagers.
A less ambitious approach would be creating/extending a static analyser/linter for Nix (there are already a few out there). This could nudge packagers towards certain styles, which language implementations could optimise for.
For example, an interpreter could have multiple implementations of the attrset interface (key/value mappings) with different performance characteristics, using some default for literals like '{ foo = "bar"; }' and a specialised version for known use-cases like nixpkgs.lib.nameValuePair ( https://github.com/NixOS/nixpkgs/blob/e9e53499b26ad98ac97f97... ) (mentioned in a sibling)
Linters could then spot when such functions are appropriate, e.g.
Found literal name/value pair on line 123:
That's not what anyone is doing though. You can run Nix with minor tweaks to e.g. its garbage collector settings[0] and you'll quickly see it crash in various ways. Memory safety is a real concern in programs, not a buzzword.
[0]: https://github.com/ivmai/bdwgc/blob/master/doc/README.enviro...
There are some technical objections to the design of flakes, but the controversy in the community is primarily social imo.
The reading I'd recommend as someone sympathetic to both 'sides' isn't really a technical comparison, but this: https://grahamc.com/blog/flakes-are-an-obviously-good-thing
As far as technical pros and cons, it's worth looking at colemickens' PoC demonstrating that in principle, you can use Nix to generate literally identical output with and without flakes: https://github.com/colemickens/nixos-flake-example
Keep in mind I use Nix personally, and for work.
> I too bought the story that being able to re-emerge my whole system was some kind of performance or configuration boon. Eventually I realized that I just wanted to use my computer to get through life...
I don't have fun constantly mucking with my settings either. That novelty long wore off long ago, like with most people who have used Linux 10+ years.
I do however get a benefit being able to set up my same config on multiple machines. For example, recently, I switched from XMonad to sway on my work computer, which necessitated a bunch of config changes. I then synced those changes over to my personal machine with https://github.com/nix-community/home-manager .
C.f. my phone just died, and I got a new android, and the android backup/sync situation gets worse and worse, and it will be a huge pain in the ass fixing my phone so i can hopefully move a few more account settings, 2FAs, etc. over.
The moral of the story is that when I do need to configure something, I want to do it once. Sysadmining repetitively is infuriating.
-----
The linker thing is quite different. I still do like programming (as opposed to sysadmining) for fun, and I want the tools to suck less. I also find infrastructure fun and interesting, be it computer or real world. I am a fairly prolific contributor to the Nix ecosystem, not because what I necessary want to do by myself on my own machine, but simply because I enjoy making the stuff better (and this hobby also sometimes becomes current task on the job, too).
Nix starts from a strong baseline of "sound" builds --- anything that is not sand-boxed, and therefore unlikely to be reproducible / cached correctly now pisses me off a shitty software that doesn't respect by time. The goal is to build on that foundation and also make Nix builds more incremental, so we have both a reliable and tight debug loop. Ultimately I want to see my work and the Nix community at large swamp the rest of the computing world with the productivity that is unleashed and when we stop crippling ourselves with shitty tools.
The flip side is that since goal is social, I have 0 interest in solo dog-fooding. I only use my PRs which I merged upstream; whatever benefits they would bring are certainly outweighed by the costs of living on forks all by oneself.
-----
If not being totally relatable (I rarely find people interested infra changes that don't immediately benefit them) hopefully it is at least clearly distinct from "building out my person nerd terrarium" customizing the computer as individualistic self-expression.