Tvix – A New Implementation of Nix

Said it downthread, but saying it again because it bears repeating:

This is a product whose major contributors live in a state prone to very persuasive forms of coercion. Worse, this is a _build system_. Moreover, it's one of the most reticulate build systems on the planet -- I doubt more than a few hundred senior engineers would be able to spot a Jia-Tan-style compromise in the Nix machinery, let alone a remix/workalike of it.

There is currently a war going on. Not a 'war on' drugs, or cancer, or a 'culture war', or any of the other phenomena that Americans routinely nowadays call a 'war', but an actually-actual conflagration involving grads, kinzhals, and, easily, the futures of a couple of well-intentioned engineers in Moscow.

I expect the creators of this product are sincere, serious, smart, kind, generous, funny, honorable people. Yet it is simply too plausible that the FSB could come by and lean on them (or their uncle, or mother, or sister, or...) and have a little something extra put at the very root of the tree, from where it could be folded into any (or every) part of the system.

Open source across international borders is a peacetime phenomenon, as we are all about to discover, methinks. I hope I'm wrong.

I'm responding to their suggestion to travel to Moscow. FWIW I am very excited to see a rust impl of Nix focused on performance, and I am completely understanding that a person cannot pick their nationality (to some degree).

Fuzzy completion makes it trivial, although it doesn't help with the unreadable part.

Spelunking in nix store dirs directly is usually unnecessary, though. You can debug/tinker with your derivations in nix shell (or, confusingly as always, nix-shell).

I would recommend against using Tvix at this time, but if you are wondering why they wrote it, they wrote an article: https://tvl.fyi/blog/rewriting-nix

The goals they list are:

> Creating an alternative implementation of Nix that is fully compatible with nixpkgs.

No explanation needed.

> More efficient Nix language evaluation, leading to greatly increased performance.

The Nix language is evaluated whenever doing the Nix equivalent of installing a package, or rebuilding your configuration. Note that most of the time it's "fast enough" but the authors of Tvix are doing more with the Nix language (which leads into)

> No more strict separation of evaluation and build phases: Generating Nix data structures from build artefacts ("IFD") should be supported first-class and not incur significant performance cost.

and

> Well-defined interaction protocols for how the three different components (evaluator, builder, store) interact.

As it currently works, the Nix language is evaluated to something called a derivation, which is a specific format for defining how to build something (including a list of dependencies). The derivation is then used to actually build the artifact. This is about when you want the metaphorical snake to eat its tail and have the results of a derivation be more nix language to evaluate.

> A builder implementation using OCI instead of custom sandboxing code.

Hermetic builds require some sandboxing; Using OCI containers seems like an obvious choice, but didn't exist when Nix was first created.

> us evakyated

huh?