TVL blog

Tvix Status - August '24

2024-08-09T16:02:50+00:00

It's already been around half a year since the last Tvix update, so time for another one!

Note: This blog post is intended for a technical audience that is already intimately familiar with Nix, and knows what things like derivations or store paths are. If you're new to Nix, this will not make a lot of sense to you!

Builds

A long-term goal is obviously to be able to use the expressions in nixpkgs to build things with Tvix. We made progress on many places towards that goal:

Drive builds on IO

As already explained in our first blog post, in Tvix, we want to make IFD a first-class citizen without significant perf cost.

Nix tries hard to split Evaluation and Building into two phases, visible in the nix-instantiate command which produces .drv files in /nix/store and the nix-build command which can be invoked on such .drv files without evaluation. Scheduling (like in Hydra) usually happens by walking the graph of .drv files produced in the first phase.

As soon as there's some IFD along the path, everything until then gets built in the Evaluator (which is why IFD is prohibited in nixpkgs).

Tvix does not have two separate "phases" in a build, only a graph of unfinished Derivations/Builds and their associated store paths. This graph does not need to be written to disk, and can grow during runtime, as new Derivations with new output paths are discovered.

Build scheduling happens continuously with that graph, for everything that's really needed, when it's needed.

We do this by only "forcing" the realization of a specific store path if the user ultimately wants that specific result to be available on their system, and transitively, if something else wants it. This includes IFD in a very elegant way.

We want to play with this approach as we continue on bringing our build infrastructure up.

Fetchers

There's a few Nix builtins that allow describing a fetch (be it download of a file from the internet, clone of a git repo). These needed to be implemented for completeness. We implemented pretty much all downloads of Tarballs, NARs and plain files, except git repositories, which are left for later.

Instead of doing these fetches immediately, we added a generic Fetch type that allows describing such fetches before actually doing them, similar to being able to describe builds, and use the same "Drive builds on IO" machinery to delay these fetches to the point where it's needed. We also show progress bars when doing fetches.

Very early, during bootstrapping, nixpkgs relies on some builtin:fetchurl "fake" Derivation, which has some special handling logic in Nix. We implemented these quirks, by converting it to instances of our Fetch type and dealing with it there in a consistent fashion.

More fixes, Refscan

With the above work done, and after fixing some small bugs ¹, we were already able to build some first few store paths with Tvix and our runc-based builder 🎉!

We didn't get too far though, as we still need to implement reference scanning, so that's next on our TODO list for here. Stay tuned for further updates there!

Eval correctness & Performance

As already written in the previous update, we've been evaluating parts of nixpkgs and ensuring we produce the same derivations. We managed to find and fix some correctness issues there.

Even though we don't want to focus too much on performance improvements until all features of Nix are properly understood and representable with our architecture, there's been some work on removing some obvious and low-risk performance bottlenecks. Expect a detailed blog post around that soon after this one!

Tracing / O11Y Support

Tvix got support for Tracing, and is able to emit spans in OpenTelemetry-compatible format.

This means, if the necessary tooling is set up to collect such spans ², it's possible to see what's happening inside the different components of Tvix across process (and machine) boundaries.

Tvix now also propagates trace IDs via gRPC and HTTP requests ³, and continues them if receiving such ones.

As an example, this allows us to get "callgraphs" on how a tvix-store operation is processed through a multi-node deployment, and find bottlenecks and places to optimize performance for.

Currently, this is compiled in by default, trying to send traces to an endpoint at localhost (as per the official SDK defaults). It can be disabled by building without the otlp feature, or running with the --otlp=false CLI flag.

This piggy-backs on the excellent tracing crate, which we already use for structured logging, so while at it, we improved some log messages and fields to make it easier to filter for certain types of events.

We also added support for sending out Tracy traces, though these are disabled by default.

Additionally, some CLI entrypoints can now report progress to the user! For example, when we're fetching something during evaluation (via builtins.fetchurl), or uploading store path contents, we can report on this. See here for an example.

We're still considering these outputs as early prototypes, and will refine them as we go.

tvix-castore ingestion generalization

We spent some time refactoring and generalizing tvix-castore importer code.

It's now generalized on a stream of "ingestion entries" produced in a certain order, and there's various producers of this stream (reading through the local filesystem, reading through a NAR, reading through a tarball, soon: traversing contents of a git repo, …).

This prevented a lot of code duplication for these various formats, and allows pulling out helper code for concurrent blob uploading.

More tvix-[ca]store backends

We added some more store backends to Tvix:

There's a redb PathInfoService and DirectoryService, which also replaced the previous sled default backend.
There's a bigtable PathInfoService and DirectoryService backend.
The "simplefs" BlobService has been removed, as it can be expressed using the "objectstore" backend with a file:// URI.
There's been some work on feature-flagging certain backends.

Documentation reconcilation

Various bits and pieces of documentation have previously been scattered throughout the Tvix codebase, which wasn't very accessible and quite confusing.

These have been consolidated into a mdbook (at //tvix/docs).

We plan to properly host these as a website, hopefully providing a better introduction and overview of Tvix, while adding more content over time.

`nar-bridge` RIIR

While the golang implementation of nar-bridge did serve us well for a while, it being the only remaining non-Rust part was a bit annoying.

Adding some features there meant they would not be accessible in the rest of Tvix - and the other way round. Also, we could not open data stores directly from there, but always had to start a separate tvix-store daemon.

The initial plans for the Rust rewrite were already made quite a while ago, but we finally managed to finish implementing the remaining bits. nar-bridge is now fully written in Rust, providing the same CLI experience features and store backends as the rest of Tvix.

`crate2nix` and overall rust Nix improvements

We landed some fixes in crate2nix, the tool we're using to for per-crate incremental builds of Tvix.

It now supports the corner cases needed to build WASM - so now Tvixbolt is built with it, too.

We also fixed some bugs in how test directories are prepared, which unlocked running some more tests for filesystem related builtins such as readDir in our test suite.

Additionally, there has been some general improvements around ensuring various combinations of Tvix feature flags build (now continuously checked by CI), and reducing the amount of unnecessary rebuilds, by filtering non-sourcecode files before building.

These should all improve DX while working on Tvix.

Store Composition

Another big missing feature that landed was Store Composition. We briefly spoke about the Tvix Store Model in the last update, but we didn't go into too much detail on how that'd work in case there's multiple potential sources for a store path or some more granular contents (which is pretty much always the case normally, think about using things from your local store OR then falling back to a remote place).

Nix has the default model of using /nix/store with a sqlite database for metadata as a local store, and one or multiple "subsituters" using the Nix HTTP Binary Cache protocol.

In Tvix, things need to be a bit more flexible:

You might be in a setting where you don't have a local /nix/store at all.
You might want to have a view of different substituters/binary caches for different users.
You might want to explicitly specify caches in between some of these layers, and control their config.

The idea in Tvix is that you'll be able to combine "hierarchies of stores" through runtime configuration to express all this.

It's currently behind a xp-store-composition feature flag, which adds the optional --experimental-store-composition CLI arg, pointing to a TOML file specifying the composition configuration. If set, this has priority over the old CLI args for the three (single) stores.

We're still not 100% sure how to best expose this functionality, in terms of the appropriate level of granularity, in a user-friendly format.

There's also some more combinators and refactors missing, but please let us know your thoughts!

Contributors

There's been a lot of progress, which would not have been possible without our contributors! Be it a small drive-by contributions, or large efforts, thank you all!

Adam Joseph
Alice Carroll
Aspen Smith
Ben Webb
binarycat
Brian Olsen
Connor Brewster
Daniel Mendler
edef
Edwin Mackenzie-Owen
espes
Farid Zakaria
Florian Klink
Ilan Joselevich
Luke Granger-Brown
Markus Rudy
Matthew Tromp
Moritz Sanft
Padraic-O-Mhuiris
Peter Kolloch
Picnoir
Profpatsch
Ryan Lahfa
Simon Hauser
sinavir
sterni
Steven Allen
tcmal
toastal
Vincent Ambo
Yureka

That's it again, try out Tvix and hit us up on IRC or on our mailing list if you run into any snags, or have any questions.

like builtins.toFile not adding files yet, or inputSources being missed initially, duh!) ↩
Essentially, deploying a collecting agent on your machines, accepting these traces. ↩
Using the traceparent header field from https://www.w3.org/TR/trace-context/#trace-context-http-headers-format ↩

Tvix Status - February '24

2024-02-09T09:48:52+00:00

We've now been working on our rewrite of Nix, Tvix, for a little more than two years.

Our last written update was in September 2023, and although we did publish a couple of things in the meantime (flokli's talk on Tvix at NixCon 2023, our interview at the Nix Developer Dialogues, or tazjin's talk on tvix-eval (in Russian)), we never found the time to write something down.

In the meantime a lot of stuff has happened though, so it's time to change that :-)

Evaluation regression testing

Most of the evaluator work has been driven by evaluating nixpkgs, and ensuring that we produce the same derivations, and that their build results end up in the same store paths.

Builds are not hooked up all the way to the evaluator yet, but for Nix code without IFD (such as nixpkgs!) we can verify this property without building. An evaluated Nix derivation's outPath (and drvPath) can be compared with what C++ Nix produces for the same code, to determine whether we evaluated the package (and all of its dependencies!) correctly ¹.

We added integration tests in CI that ensure that the paths we calculate match C++ Nix, and are successfully evaluating fairly complicated expressions in them. For example, we test against the Firefox derivation, which exercises some of the more hairy bits in nixpkgs (like WASM cross-compilation infrastructure). Yay!

Although we're avoiding fine-grained optimization until we're sure Tvix evaluates all of nixpkgs correctly, we still want to have an idea about evaluation performance and how our work affects it over time.

For this we extended our benchmark suite and integrated it with Windtunnel, which now regularly runs benchmarks and provides a view into how the timings change from commit to commit.

In the future, we plan to run this as a part of code review, before changes are applied to our canonical branch, to provide this as an additional signal to authors and reviewers without having to run the benchmarks manually.

ATerms, output path calculation, and `builtins.derivation`

We've implemented all of these features, which comprise the components needed to construct derivations in the Nix language, and to allow us to perform the path comparisons we mentioned before.

As an interesting side note, in C++ Nix builtins.derivation is not actually a builtin! It is a piece of bundled Nix code, that massages some parameters and then calls the actual builtin: derivationStrict. We've decided to keep this setup, and implemented support in Tvix to have builtins defined in .nix source code.

These builtins return attribute sets with the previously mentioned outPath and drvPath fields. Implementing them correctly meant that we needed to implement output path calculation exactly the same way as Nix does (bit-by-bit).

Very little of how this output path calculation works is documented anywhere in C++ Nix. It uses a subset of ATerm internally, produces "fingerprints" containing hashes of these ATerms, which are then hashed again. The intermediate hashes are not printed out anywhere (except if you patch Nix to do so).

We already did parts of this correctly while starting this work on go-nix some while ago, but found some more edge cases and ultimately came up with a nicer interface for Tvix.

All the Derivation internal data model, ATerm serialization and output path calculation have been sliced out into a more general-purpose nix-compat crate, alongside with more documentation unit tests and a Derivation ATerm parser, so hopefully this will now be more accessible for everyone now.

Note our builtin does not yet persist the Derivation anywhere "on disk" (though we have a debug CL that does write it to a temporary directory, in case we want to track down differences).

`tvix-[ca]store`

Tvix now has a store implementation!

The Nix model

Inside Nix, store path contents are normally hashed and communicated in NAR format, which is very coarse and often wasteful - a single bit of change in one file in a large store path causes a new NAR file to be uploaded to the binary cache, which then needs to be downloaded.

Additionally, identifying everything by the SHA256 digest of its NAR representation makes Nix store paths very incompatible with other content-addressed systems, as it's a very Nix-specific format.

The more granular Tvix model

After experimenting with some concepts and ideas in Golang, mostly around how to improve binary cache performance², both on-disk as well as over the network, we settled on a more granular, content-addressed and general-purpose format.

Internally, it behaves very similar to how git handles tree objects, except blobs are identified by their raw BLAKE3 digests rather than some custom encoding, and similarly, tree/directory objects use the BLAKE3 digest of its canonical protobuf serialization as identifiers.

This provides some immediate benefits:

We only need to keep the same data once, even if it's used across different store paths.
Transfers can be more granular and only need to fetch the data that's needed. Due to everything being content-addressed, it can be fetched from anything supporting BLAKE3 digests, immediately making it compatible with other P2P systems (IPFS blake3 blobs, …), or general-purpose content-addressed caches (bazel-remote).

There's a lot more details about the data model, certain decisions etc. in the docs.

Compatibility

We however still want to stay compatible with Nix, as in calculating "NAR-addressed" store paths the same, support substituting from regular Nix binary caches, as well as storing all the other additional metadata about store paths.

We accomplished this by splitting the two different concerns into two separate tvix-store and tvix-castore crates, with the former one holding all Nix-specific metadata and functionality, and the latter being a general-purpose content-addressed blob and filesystem tree storage system, which is usable in a lot of contexts outside of Tvix too. For example, if you want to use tvix-castore to write your own git alternative, or provide granular and authenticated access into large scientific datasets, you could!

Backends

In addition to a gRPC API and client bindings, there's support for local filesystem-based backends, as well as for sled, an embedded K/V database.

We're also currently working on a backend supporting most common object storages, as well as on more granular seeking and content-defined chunking for blobs.

FUSE/virtiofs

A tvix-store can be mounted via FUSE, or exposed through virtiofs³. While doing the obvious thing - allowing mounting and browsing the contents of the store, this will allow lazy substitution of builds on remote builders, be in containerized or virtualized workloads.

We have an example in the repository seeding gnu hello into a throwaway store, then booting a MicroVM and executing it.

nar-bridge, bridging binary caches

nar-bridge and the NixHTTPPathInfoService bridge tvix-[ca]store with existing Nix binary caches and Nix.

The former exposes a tvix-[ca]store over the common Nix HTTP Binary Cache interface (both read and write).

The latter allows Tvix to substitute from regular Nix HTTP Binary caches, unpacking NARs and ingesting them on-the-fly into the castore model. The necessary parsers for NARInfo, signatures etc are also available in the nix-compat crate.

EvalIO / builtins interacting with the store more closely

tvix-eval itself is designed to be quite pure when it comes to IO - it doesn't do any IO directly on its own, but for the very little IO functionality it does as part of "basic interaction with paths" (like importing other .nix files), it goes through an EvalIO interface, which is provided to the Evaluator struct on instantiation.

This allows us to be a bit more flexible with how IO looks like in practice, which becomes interesting for specific store implementations that might not expose a POSIX filesystem directly, or targets where we don't have a filesystem at all (like WASM).

Using the EvalIO trait also lets tvix-eval avoid becoming too strongly coupled to a specific store implementation, hashing scheme etc⁴. As we can extend the set of builtins available to the evaluator with "foreign builtins", these can live in other crates.

Following this pattern, we started implementing some of the "basic" builtins that deal with path access in tvix-eval, like:

builtins.pathExists
builtins.readFile

We also recently started working on more complicated builtins like builtins.filterSource and builtins.path, which are also used in nixpkgs.

Both import a path into the store, and allow passing a Nix expression that's used as a filter function for each path. builtins.path can also ensuring the imported contents match a certain hash.

This required the builtin to interact with the store and evaluator in a very tight fashion, as the filter function (written in Nix) needs to be repeatedly executed for each path, and its return value is able to cause the store to skip over certain paths (which it previously couldn't).

Getting the abstractions right there required some back-and-forth, but the remaining changes should land quite soon.

Catchables / tryEval

Nix has a limited exception system for dealing with user-generated errors: builtins.tryEval can be used to detect if an expression fails (if builtins.throw or assert are used to generate it). This feature requires extra support in any Nix implementation, as errors may not necessarily cause the Nix program to abort.

The C++ Nix implementation reuses the C++ language-provided Exception system for builtins.tryEval which Tvix can't (even if Rust had an equivalent system):

In C++ Nix the runtime representation of the program in execution corresponds to the Nix expression tree of the relevant source files. This means that an exception raised in C++ code will automatically bubble up correctly since the C++ and Nix call stacks are equivalent to each other.

Tvix compiles the Nix expressions to a byte code program which may be mutated by extra optimization rules (for example, we hope to eliminate as many thunks as possible in the future). This means that such a correspondence between the state of the runtime and the original Nix code is not guaranteed.

Previously, builtins.tryEval (which is implemented in Rust and can access VM internals) just allowed the VM to recover from certain kinds of errors. This proved to be insufficient as it blew up as soon as a builtins.tryEval-ed thunk is forced again – extra bookkeeping was needed. As a solution, we now store recoverable errors as a separate runtime value type.

As you can imagine, storing evaluation failures as "normal" values quickly leads to all sorts of bugs because most VM/builtins code is written with only ordinary values like attribute sets, strings etc. in mind.

While ironing those out, we made sure to supplement those fixes with as many test cases for builtins.tryEval as possible. This will hopefully prevent any regressions if or rather when we touch this system again. We already have some ideas for replacing the Catchable value type with a cleaner representation, but first we want to pin down all the unspoken behaviour.

String contexts

For a long time, we had the working theory that we could get away with not implementing string contexts, and instead do reference scanning on a set of "known paths" (and not implement builtins.unsafeDiscardStringContext).

Unfortunately, we discovered that while this is conceptually true, due to a bug in Nix that's worked around in the stdenv.mkDerivation implementation, we can't currently do this and calculate the same hashes.

Because hash compatibility is important for us at this point, we bit the bullet and added support for string contexts into our NixString implementation, implemented the context-related builtins, and added more unit tests that verify string context behaviour of various builtins.

Strings as byte strings

C++ Nix uses C-style zero-terminated strings internally - however, until recently, Tvix has used standard Rust strings for string values. Since those are required to be valid UTF-8, we haven't been able to properly represent all the string values that Nix supports.

We recently converted our internal representation to byte strings, which allows us to treat a Vec<u8> as a "string-like" value.

JSON/TOML/XML

We added support for the toJSON, toXML, fromJSON and fromTOML builtins.

toXML is particularly exciting, as it's the only format that allows expressing (partially applied) functions. It's also used in some of Nix' own test suite, so we can now include these in our unit test suite (and pass, yay!).

Builder protocol, drv->builder

We've been working on the builder protocol, and Tvix's internal build representation.

Nix uses derivations (encoded in ATerm) as nodes in its build graph, but it refers to other store paths used in that build by these store paths only. As mentioned before, store paths only address the inputs - and not the content.

This poses a big problem in Nix as soon as builds are scheduled on remote builders: There is no guarantee that files at the same store path on the remote builder actually have the same contents as on the machine orchestrating the build. If a package is not binary reproducible, this can lead to so-called frankenbuilds.

This also introduces a dependency on the state that's present on the remote builder machine: Whatever is in its store and matches the paths will be used, even if it was maliciously placed there.

To eliminate this hermiticity problem and increase the integrity of builds, we've decided to use content-addressing in the builder protocol.

We're currently hacking on this at Thaigersprint and might have some more news to share soon!

That's it for now, try out Tvix and hit us up on IRC or on our mailing list if you run into any snags, or have any questions.

เจอกันนะ :)

We know that we calculated all dependencies correctly because of how their hashes are included in the hashes of their dependents, and so on. More on path calculation and input-addressed paths in the next section! ↩
See nix-casync for one example - investing content-defined chunking (while still keeping the NAR format) ↩
Strictly speaking, not limited to tvix-store - literally anything providing a listing into tvix-castore nodes. ↩
That's the same reason why builtins.derivation[Strict] also lives in tvix-glue, not in tvix-eval. ↩

Tvix Status - September '22

2022-09-12T15:12:14+00:00

We've now been working on our rewrite of Nix, Tvix, for over a year.

As you can imagine, this past year has been turbulent, to say the least, given the regions where many of us live. As a result we haven't had as much time to work on fun things (like open-source software projects!) as we'd like.

We've all been fortunate enough to continue making progress, but we just haven't had the bandwidth to communicate with you and keep you up to speed on what's going on. That's what this blog post is for.

Nix language evaluator

The most significant progress in the past six months has been on our Nix language evaluator. To answer the most important question: yes, you can play with it right now – in Tvixbolt!

We got the evaluator into its current state by first listing all the problems we were likely to encounter, then solving them independently, and finally assembling all those small-scale solutions into a coherent whole. As a result, we briefly had an impractically large private source tree, which we have since integrated into our monorepo.

This process was much slower than we would have liked, due to code review bandwidth... which is to say, we're all volunteers. People have lives, bottlenecks happen.

Most of this code was either written or reviewed by grfn, sterni and tazjin (that's me!).

How much of eval is working?

Most of it! You can enter most (but not all, sorry! Not yet, anyway.) Nix language expressions in Tvixbolt and observe how they are evaluated.

There's a lot of interesting stuff going on under the hood, such as:

The Tvix compiler can emit warnings and errors without failing early, and retains as much source information as possible. This will enable you to use Tvix as the basis for developer tooling, such as language servers.
The Tvix compiler performs in-depth scope analysis, so it can both generate efficient bytecode for accessing identifiers, and alert you about problems in your code before runtime.
The runtime supports tail-call optimisation in many (but – again – not yet all) cases, so you can evaluate recursive expressions in constant stack space.
The runtime can give you different backing representations for the same Nix type. For example, an attribute set is represented differently depending on whether you've constructed an empty one, a name/value pair, or a larger set. This lets us optimise frequent, well-known use-cases without impacting the general case much.

We've run some initial benchmarks against C++ Nix (using the features that are ready), and in most cases Tvix evaluation is an order of magnitude faster. To be fair, though, these benchmarks are in no way indicative of real-life performance for things like nixpkgs. More information is coming... eventually.

How does it all work?

Tvix's evaluator uses a custom abstract machine with a Nix-specific instruction set, and a compiler that traverses a parsed Nix AST to emit this bytecode and perform a set of optimisations and other analysis. The most important benefit of this is that we can plan and lay out the execution of a program in a way that is better suited to an efficient runtime than directly traversing the AST.

TIP: You can see the generated bytecode in Tvixbolt!

This is all written in about 4000 lines of Rust (naturally), some of which – especially around scope-handling – are deceptively simple.

As part of our CI suite, we run the evaluator against some tests we wrote ourselves, as well as against the upstream Nix test suite (which we don't quite pass yet. We're working on it!).

What's next for tvix-eval?

Despite all our progress, there are still some unfinished feature areas, and some of them are pretty important:

The majority of Nix's builtins – including fundamental ones like import and derivation – aren't implemented yet.
Neither are recursive attribute sets (rec). This isn't because of a problem with the recursion itself, but because of the handling of nested keys (such as a.b). We have a lackluster solution already, but are designing a more efficient one.

In both cases, we've mostly figured out what to do; now it's just a matter of finding the time to do it. Our progress is steady, and can be tracked in the source (viewer without Javascript here).

Apart from that, the next steps are:

Comprehensive benchmarking. We're standing up an infrastructure for continuous benchmarking to measure the impact of changes. It'll also let us identify and optimise hotspots
Implementing known optimisations. There are some areas of the code that have the potential for significant speed gains, but we're holding off implementing those until the evaluator is feature complete and passes the Nix test suite.
Finishing our language specification. Based on what we've learned, we're writing a specification of the Nix language that captures its various behaviours in all their tricky subtlety and subtle trickery.

Once we can evaluate nixpkgs, we're likely to shift our focus towards the other areas of Tvix.

The Other Areas of Tvix

Speaking of these other areas (most importantly, the builder and store implementation), we've made some nice progress there also.

While we've yet to start assembling the actual pieces, flokli and adisbladis have been hard at work on go-nix, which aims to implement many of the low-level primitives required for the Nix store and builder (hashing and encoding schemes, archive formats, reference scanning ...).

We're looking forward to telling you more in the next Tvix status update!

Outro ...

We'd be delighted to onboard new contributors to Tvix! Please take a look at the main TVL page to find out how to get in touch with us if you'd like to join!

Thanks also, of course, to NLNet for sponsoring some of this work!

And finally, we would like to thank and pay our respects to jD91mZM2 – the original author of rnix-parser – who has sadly passed away. Please, tell people how important they are to you.

We use rnix-parser in our compiler, and its well-designed internals (also thanks to its new maintainers!) have saved us a lot of time.

That's it for this update. Go play with Tvixbolt, have fun figuring out weird ways to break it – and if you do, let us know.

We'll see you around!

Tvix: We are rewriting Nix

2021-12-01T17:56:27+00:00

Evaluating the Nix programming language, used by the Nix package manager, is currently very slow. This becomes apparent in all projects written in Nix that are not just simple package definitions, for example:

the NixOS module system
TVL projects like //nix/yants and //web/bubblegum.
the code that generates build instructions for TVL's CI setup

Whichever project you pick, they all suffer from issues with the language implementation. At TVL, it takes us close to a minute to create the CI instructions for our monorepo at the moment - despite it being a plain Nix evaluation. Running our Nix-native build systems for Go and Common Lisp takes much more time than we would like.

Some time last year a few of us got together and started investigating ways to modernise the current architecture of Nix and figure out how to improve the speed of some of the components. We created over 250 commits in our fork of the Nix 2.3 codebase at the time, tried performance experiments aimed at improving the current evaluator and fought gnarly bugs.

After a while we realised that we were treading water: Some of our ideas are too architecturally divergent from Nix to be done on top of the existing codebase, and the memory model of Nix causes significant headaches when trying to do any kind of larger change.

We needed an alternative approach and started brainstorming on a bent whiteboard in a small flat in Hurghada, Egypt.

Half a year later we are now ready to announce our new project: Tvix, a re-imagined Nix with full nixpkgs compatibility. Tvix is generously funded by NLNet (thanks!) and we are ready to start implementing it.

The Tvix architecture is designed to be modular: It should be possible to write an evaluator that plugs in the Guile language (for compatibility with GNU Guix), to use arbitrary builders, and to replace the store implementation.

Tvix has these high-level goals:

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

The package collection is an enormous effort with hundreds of thousands of commits, encoding expert knowledge about lots of different software and ways of building and managing it. It is a very valuable piece of software and we must be able to reuse it.
More efficient Nix language evaluation, leading to greatly increased performance.
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.
Well-defined interaction protocols for how the three different components (evaluator, builder, store) interact.
A builder implementation using OCI instead of custom sandboxing code.

Tvix is not intended to replace Nix, instead we want to improve the ecosystem by offering an alternative, fast and reliable implementation for Nix features that are in use today.

As things ramp up we will be posting more information on this blog, for now you can keep an eye on //tvix in the TVL monorepo and subscribe to our feed.

Stay tuned!

PS: TVL is international, but a lot of the development will take place in our office in Moscow. Say hi if you're around and interested!