Making Nix Usable With Rust

Drew: What led you to becoming a software engineer at Flox?

Zach: I've been writing software in one form or another for about a decade, but not professionally. My background is actually physics. A little over a year ago, I was working full time as a software engineer while finishing my PhD, which is an insane thing to do and I don’t recommend it. Once I defended, I took some time to remember how to be a human being again. Then, in January of 2023, I started learning Nix because I had read a lot about it. It seemed like it was an interesting tool for setting up development environments and builds and stuff like that. I know for me personally, when I set up a new machine, it's kind of a pain because you're like, okay, how do I get this set up exactly the same way as the previous one? The idea of being able to put a development environment in one file and only have it available when I work on that project was very appealing. I also have a thing for documentation. So, one of the first things I did was write a blog post series that was documenting my journey learning Nix. The first thing I ran into was that the Nix docs are really hard to use. One of my first posts in that series was what I called my “Grand Unified Theory of Nix Documentation”, which was just me saying here's what I want the docs to look like. That got some attention. The person who runs the Nix documentation team reached out to me, and I ended up joining the team and working on documentation rather than putting it on my blog. Also, Ron, who is now my CEO, is on the NixOS Foundation board. He reached out and asked if I wanted to talk about the docs. While we were talking about that, he basically asked if I would be interested in a role at Flox? I said sure. The rest is kind of history. That was exciting because I was both interested in Nix and in using Rust. So it was kind of like, check, check, yes, please.

Zach: So that's how I got started at Flox. How I got started at software engineering was grad school. I had taken a numerical techniques course in undergrad, which is basically solving differential equations with computers. That was in MATLAB. When I joined my lab, I decided that MATLAB licenses are expensive and MATLAB is just not super fun. So, I started using Python and NumPy. If you fast forward several years, I'd become the person in charge of writing all the software for the lab. I even started programming on the side, as a hobby. I started going to meetups, started attending conferences, and started writing blog posts. Eventually I got interested in systems programming. But, I always heard that it was notoriously hard to do C or C++ correctly. At the same time, Rust was becoming more a part of people's awareness. So I started learning Rust in 2018. It's been about six years since I started writing Rust. I figured out part of the way through my PhD that I wanted to do software engineering. At the time, I was like, I'll just finish my PhD, it'll only be like two more years. That was very wrong. It proceeded to take a lot more than two more years. But, anyway, I stuck it out.

Drew: It's interesting that you just kind of let your interest flow where it willed. I wonder if that's a common path or not. I guess maybe it is for folks in physics or math where you get exposed to programming as something that supports your main endeavors only to potentially realize you like it more.

Zach: Yeah, I'd say that the common theme for me was wanting to understand how things work. You don't really go into physics unless you want to understand the nitty gritty of how everything works. For me, that just kind of extended to computers. How does a program get loaded into memory? How does a program execute? Those types of questions are where the interest in systems programming came from. I find that I have a really hard time using tools if I don't understand what they're doing. If somebody hands me a tool and says, here, just press this magic button, it’s a no. You have to tell me what the button does. This is one of the things that makes containers kind of complex to me. You have kernel level features that you're using, like cgroups, namespaces, and stuff like that. It also has its own network that you have to like poke holes into in order to connect to other services. Then, you have to add volumes in order to poke another hole into it to get files in and out. It makes me wonder if this is really how we're supposed to be doing things.

Drew: I can relate to that a bit. I feel like even though I think I understand containers fairly well, it still feels pretty opaque to me. And, that means if something really weird goes wrong, I’m really hung out to dry.

Zach: I still think that containers work really well as a distribution format. But for development environments, they leave something to be desired.

Drew: Before we talk more containers and such, one more thing I wanted to note about your background is that I think it's really cool that you got your job at Flox by getting kind of ingrained in the Nix community and contributing there. And then it sounds like the job kinda fell out of that.

Zach: Exactly. I always had an interest in teaching. When I was in my PhD, I actually got a couple of department wide and university wide teaching awards. I really liked that part of the job. So, I noticed when I got into Nix that the documentation is really hard to use. This meant Nix was very hard to learn. So I was like, okay, I can teach. I’ll teach and learn Nix along the way. I have a blog because I like teaching is what it really boils down to.

Drew: I think that's a really good path for getting a job. There's so much learning on the job that you do in software engineering that you're never going to avoid that. But, if you find something that you're interested in and apply your unique skills to it, that's a very strong place to be coming from in terms of getting a foot in the door.

Zach: It has paid dividends. I'll also say that the previous job I got was also through my blog. In that case, I was working on this quantum mechanics simulation for my PhD that would sometimes take like eight hours to run. I eventually sped it up by about 50 times on the same machine through algorithmic improvements, profiling, and rewriting the core in Rust. Then I got a faster machine (an M1 Max Macbook Pro), and that sped it up to like 250 times. I wrote up a blog post about the steps that I took to make it faster, and put a small note at the end that said “by the way, if you have a job, please hire me”. A bunch of people reached out, and one of them was the job that I ended up taking.

Drew: There's a lot of people I've interviewed who have a similar story specifically about blogs. I think that as a software engineer, you like to think that you don't have to think about marketing and sales. But, you have to at least tell people what you're doing.

Zach: Even within an organization, soft skills make a huge difference. You can be like the next coming of Alan Turing or whoever, but if you're just a huge jerk, nobody cares. So being able to explain your ideas or talk through issues is big. Engineering is a team sport.

Drew: Our plan here is to talk about your work at Flox. I think we should cover Nix before in case people don't have a foundation of what Nix is. So, one of the first questions I have is around all the different things that carry the Nix name. Can you break that down?

Zach: So at its core, Nix is a platform for building and configuring software, which is a very vague answer because Nix can do a lot of things. It can do everything from creating a text file to configuring an entire operating system in the case of NixOS. So, let's focus on the building software and the setting up of development environments. I’ll start with a Rust analogy. One of the reasons that people use Rust is that it enforces correctness and memory safety. It has a couple of mechanisms for doing that, like immutability, the borrow checker, a strong type system, and so forth. So, Rust is trying to enforce correctness while you're writing software. Nix is trying to enforce correctness while you're building software. It has its own set of mechanisms for doing that, one of which is also immutability. One of the things that Nix does is it allows you to set up these bulletproof development environments without using containers. Under the hood, Nix is really just files, directories, symlinks, environment variables, and shell scripts. These are just UNIX fundamentals that have existed for decades. The fact that it doesn't need kernel level support for any of those mechanisms is one of the reasons why I think it’s simpler than containers. Now, there will probably be a lot of people who hear me say Nix and simple in the same sentence and immediately bail, but if you ignore the Nix language for a minute, what it's doing under the hood is actually very simple.

Zach: Anyway, you asked about the different players in the Nix ecosystem. So, “capital N” Nix is two things. It’s the name of the ecosystem and it's also the name of a programming language. You use the Nix programming language to specify how you want your software built or how you want your development environment to be. Anything that you want to tell Nix how to do, you can do it through this programming language. If you squint really hard, Nix the language looks a lot like JSON plus pure functional programming.

Zach: Then, “lowercase N” nix is the command line tool. You use that to build your software, enter your development environments, and just generally to interact with the ecosystem.

Zach: Then there's Nixpkgs, which is also two things. The first thing is like a standard library for Nix. It has a bunch of helper functions for creating development shells, building your software, downloading software, and so on. The other thing is a software repository, but it doesn't actually contain the software itself. It contains a bunch of recipes for building that software. The recipes I mentioned are basically functions that take dependencies as arguments. The output of that function is an artifact. That artifact could be your compiled binary, your text file, or the configuration for an operating system. When you go to build your software, Nix basically goes and finds the recipes for the dependencies you asked for. Then those recipes ask for certain recipes. So, you get an entire dependency tree. At build time, it will essentially lock that whole tree.

Zach: NixOS is a Linux distribution that is built and configured using the Nix language. So, in the same way that you use the Nix language to create a development shell that has certain packages in it, you also can also get a Linux distribution that has particular services running. Pretty much anything that you might want to configure about your system, you can with NixOS.

Zach: One of the things I'll call out is that you can use Nix the tool on MacOS or Linux. So, you don't have to use NixOS in order to use Nix. There's also some very early work in progress to bring Nix to Windows. But, I would say that's probably several years off. There's also some efforts to make it work on FreeBSD, but I wouldn't say that's a main community focus.

Drew: So can you use it on WSL?

Zach: Yeah so everybody can use it for the most part. If you want to use Nix, there's almost certainly a way for you to do it.

Drew: This was kind of interspersed in your last answer, but I'm gonna ask it again and see if it draws anything else out. What are the main advantages that you would point out of using Nix?

Zach: I'd say that the main advantage is that it makes the software that you've built bulletproof in the sense that you depend on the software that you think you depend on. The same goes for development environments. Nix tries really hard to make sure that you can't build your software accidentally.

Drew: What does that mean?

Zach: Say that you install package A, and that installs libfoo on your system. Now you install package B, and that also installs a version of libfoo, and it overwrites the previous one. And, let's say that they even have the same semantic version, but somehow the version that package B gave you is slightly different. Maybe it has some security patch applied. All the software that relied on libfoo is now different because libfoo is different. So, you may not have changed anything about the software that you're running, but now it's operating slightly differently because the software that it depends on is slightly different. That's one of the problems that Nix is trying to address.

Zach: I also mentioned mutability earlier. For example, Rust tries really hard to avoid shared mutable state because it turns out that doing anything correctly with shared mutable state is really hard. Well, one example of a big ball of shared mutable state is your file system. You have a couple of common directories like /usr/local/bin, /usr/lib, and so on. When you install stuff, often it just gets dropped in those directories. Maybe it overwrites something. Maybe it doesn't. Who knows? You also just end up with a bunch of cruft in there because something may not uninstall completely or whatever. Nix stores all of the software that it builds and installs in what is essentially a giant immutable build cache called the Nix store. It's immutable in the sense that once you put something in there, it doesn't really get modified. Maybe there's some edge cases that I'm not aware of, but generally once something's in there, it doesn't get modified. The Nix store is really just a directory. In 99% of cases, the name is just “/nix/store”. Everything in that store has a hash in its file name. Since Nix keeps track of the whole dependency tree, the hash for your particular artifact is essentially the hash of its entire dependency tree. Since that path is unique, you can use it to refer to this unique piece of software. When Nix builds software, one of the things that it does is hard code these absolute paths that contain hashes in them into the binary. For instance, if you have a binary that links against a dynamic library, Nix will say link against “/nix/store/<hash>-libfoo”, which makes it essentially impossible to link against the wrong version. That's one of the things that makes software built with Nix bulletproof in terms of reproducibility. Nix also makes wrapper scripts for some things, and it will call binaries by absolute path. So, rather than just saying “bash”, it’ll say “/nix/store/<hash>-bash”. That makes it hard to use the wrong version of Python or Bash or whatever. When you go to set up development environments, you get the same benefits. Depending on how you use Nix, you may also get a lock file so that whenever you enter that development shell, you're getting those specific versions of all those pieces of software. The other thing that Nix does is build in a sandbox. It only provides the software that you've specifically asked for. This is both great and very frustrating, because you’ll find out that you have dependencies that you didn't know about. For example, if you ever compile Rust with Nix on macOS, you'll find out that you're missing libiconv, which has something to do with UTF-8. I have no idea. I just know that every Rust project I compile with Nix needs that added. So, you find out what your actual dependencies are and lock those versions. That way, when you compile something tomorrow after running “apt update”, you don't have the wrong version of a system library. One of the other benefits is that Nix development environments are native. They don't run inside of containers, so they don't need to run on a VM as is the case with containers on MacOS.

Drew: Nix, from my research, is at least in software years, pretty old.

Zach: Yeah, it's older than Git, actually.

Drew: Wow. Okay. So why isn't it everywhere?

Zach: A lot of people have a lot of thoughts about that. Some people will say that it's just so powerful that people don't know how to use it yet. I don't think that's the case. I think that's a little bit self-congratulatory. I think one of the biggest issues is that Nix is a completely different paradigm from what people are used to. If you've used one package manager, you've kind of used them all. You have install, uninstall, search, upgrade, that kind of thing. And you likely know the tools for your specific language pretty well. For example, cargo build, cargo run, etc. With Nix, none of those are helpful. In order to build your software with Nix, you have to write a program in a lazily evaluated functional programming language that nobody knows exists. That’s just incredibly different than people are used to. And, it's incredibly frustrating when you can't carry over your knowledge to accomplish something that feels pretty simple. There is a positive side to this which is that Nix presents a consistent interface for building any software. That means that you can go modify how a package is built without knowing how it's built. You also have to know the Nixpkgs library. That can be very intimidating and confusing to new users. I also mentioned the documentation. I worked on the documentation team for about nine months, and I can confidently say that the Nix documentation is really hard to use. To make matters worse, it's not really that Nix has a lack of documentation. It's kind of the opposite. There's three or four different, very extensive manuals. That leads to a different problem, which is figuring out which one has the answer you’re looking for? Because of the trouble with the documentation, most people just kind of throw their hands up and say, screw this, I'm going to go read like 18 blog posts to figure out what I'm actually supposed to do. There's also some lack of polish in terms of user experience. And, the community is very small.

Zach: Those are the blockers for individual adoption, but there's a separate problem when it comes to adoption at a company. Here's a story that you will hear over and over again, and I know this from personal experience at my previous company. You get a couple of people at a company who get really excited about Nix and want to use it internally, despite the fact that nobody else at the company knows Nix. This is strike one. Then, somebody lets them. This is strike two. So, they set up Nix, some time passes and pretty soon developers need to make changes to their development environments or infrastructure or whatever. But, these people don't know Nix. So, they need to schedule time with one of the Nix wizards. That doesn't scale. That ends up being strike three. These companies eventually painfully migrate back to containers or VMs.

Drew: That makes sense. The point that really resonated with me was the fact that it's a wholly different paradigm. When I was researching, I saw people saying that the Nix language itself is hard. Is that true or is it more just that people don't want to have to learn a new language just for configuration?

Zach: I'm certainly not going to invalidate somebody's experience if they say the language is hard. There’s also a lot that they could mean by hard. Are the error messages bad? Is the documentation bad? Is it, you know, too verbose or something like that? It's certainly different, I'll give you that. I think one of the big barriers is that it's a functional language, which a lot of people don't have experience with. But, in general, I'd say that getting used to the language is not the hardest part of Nix. A lot of it comes down to knowing which functions to call and what the arguments to them mean. I could see that getting conflated with the language itself.

Drew: So, Flox is kind of pursuing this open core model on top of Nix. I assume then that a lot of what Flox is doing is trying to smooth over some of the rough edges we’ve talked about. What is Flox adding or doing differently from plain Nix?

Zach: Certainly one of the main goals with Flox is to allow you to benefit from Nix without having to know Nix. To that extent, it's not just simply a better interface to Nix. I don't even think we call the Nix executable anywhere in the product. We have a small C++ executable that links against Nix libraries. But, we're aiming to provide a substantially better user experience out of the box. And, we're building something that's explicitly for today's users, kind of meeting them where they are. I mentioned that everybody has pretty much used a package manager before. So, we present an interface that has those familiar package manager commands like install, uninstall, search, upgrade, that kind of thing. We also provide more. We have this concept of an environment. For example, when you’re working on a project, you often want certain pieces of software available only when you’re working in that context. So, we allow you to install software to that particular environment. You can also set shell scripts that are run when you activate the environment. You can set environment variables that are present when you activate that environment. And, you can also layer these environments on top of each other and share them. So we have the familiar package manager interface if that's all you want. But, we have this entire suite of other functionality, some of which exists in Nix already and some of which does not. But under the hood, you're still getting that bulletproof software that's built with Nix and these bulletproof environments that you can take from machine to machine or from platform to platform. We're trying to make it so that if you take Flox to your tech lead or your manager, they're not going to immediately dismiss it out of hand because it's so alien. So, that's kind of what I mean by trying to meet people where they are today.

Zach: There are a few other things I should mention as well. Flox can be faster than Nix in some cases. Nix also has three different ways to enter a development environment, which can be confusing. Flox gives you one straightforward way to do it. Right now it only allows you to use Bash and Zsh, but support for other shells like Fish is on the roadmap. I'm excited for that because I just started using Fish in one of my VMs, and I really like it. I might just selfishly push that through one day. We also have plans for features that will be important for teams and organizations, like having a private catalog of software you can pull from if you have internal software or your own patches to existing open source software. When you really get down to it, what we’re doing is all about user experience.

Drew: You and I talked before recording about the fact that I'm pretty excited about and interested in what Flox is doing. My interest is mostly because I use containers a lot in my own development environments to try to address some of the problems we’ve talked about. So, there are a couple of questions that I had around containers versus Nix or in this case Flox. So, one of the things I asked about was build times. With containers, especially if I'm starting a project, there's a lot of fiddling with the environment to get it where I want. And, a lot of times that means a full rebuild with containers. That can be pretty painfully slow. What does that look like with Flox?

Zach: So, in order to set up an environment with Flox you basically just Flox install whatever packages you want. That goes and downloads those packages from the Nix binary cache and puts them in your store. So basically, that's limited by the speed of your internet connection. And then under the hood it’s really just adding a line to a text file, adding a symlink somewhere, and you're off to the races.

Zach: One of the things I like about Flox is that it has a lot of composition both in its implementation and its usage. One example is that Flox environments are composed at the package level. For instance, if I wanted to create two different containers that had the same software in them, you'd have to build both of those from scratch, right? But, if I wanted to create two different Flox environments that have the same packages in them, for the second environment the packages are already on my system, cached locally in my Nix store. So Nix and by extension Flox makes heavy use of caching. That allows you to avoid work that you'd have to do otherwise in a container. Also, if I wanted to add a new package to a container, how long that takes depends on where I add it. If it's one of the earlier layers, then I still have to rebuild all the later layers. What's more likely is that you have one giant RUN command for your container that does “apt update” and installs the 15 binaries that you care about. If you just tack on an extra package there, you have to do that whole install command again. So like you said, that's painful. That's not something that you like sitting through. But with Flox, because it's really composed out of these individual packages, incrementally adding one or removing one takes very little time.

Drew: Well, that's a point for me.

Zach: Yeah, it's pretty fast, and we have some work that's coming down the pipeline that'll make it even faster. I'm excited for that. Whenever you make your software faster, even if it's only by a little bit, it just kind of makes you giggle.

Drew: So, one of the things I like about containers is that I can basically set up the environment and hand it to someone else on a completely different system. There are some places where that doesn’t quite work, but usually that’s the case. What does that look like in the Flox/Nix world?

Zach: So, let me compare and contrast containers vs. Flox. So whether you're using a container or a VM, conceptually, you're doing a similar thing. You're taking a base system, and then you're running a sequence of commands, imperatively, that prepare the system in a certain state. You're doing this imperatively, step by step. And, it's entirely possible that something goes wrong along the way. So, if you run an image with a fixed digest, you're pretty much guaranteed to get the same system each time. But, a Dockerfile for example doesn't uniquely specify that system. So, depending on how you write your FROM line, you might encounter differences. For instance, if you put “ubuntu:latest” in there, you may get two different releases of Ubuntu. Now, even if you pin it to a specific version, two different container builds can still give you two different systems because there might be security patches that are applied. On top of the base system, even calls like update and install aren’t guaranteed to give you the same version of the package because the repositories might be in a different state that day. So, that’s not really reproducible. Running the container once it's been built is reproducible, but the build itself isn’t really reproducible.

Zach: As I mentioned before, software built with Nix is essentially hard coded to depend on other pieces of software in the Nix store, either through wrapper scripts that call specific hashed versions of a piece of software, or via an absolute path to a dynamic library. So that alone solves a lot of reproducibility problems. Flox, whenever you create an environment, also has a lock file, which says exactly which versions of a piece of software go in your environment. So, as long as you have that lock file, you can always enter an environment that has the same exact pieces of software. The same goes for what we call your manifest. The manifest is a TOML file that basically declares what you want in your environment. So, there's a lot less wiggle room there for stuff to go wrong. And I mentioned before that Nix and by extension Flox is system aware. So, in Flox, you can actually make note of the fact that a certain package doesn't exist on, for instance, macOS. So, you can either skip that package or ask for a different one. For instance, you might say on Linux, give me GDB and on MacOS, give me LLDB. That's a pretty common example.

Zach: With containers, you end up with whatever Linux system the container specifies, no matter what your host platform is. Flox layers on top of your existing system. For example, I use macOS. It's comfy. I've set it up the way that I like it, and when I enter a container, all that's gone. That's kind of a pain. As developers, we all spend too much time setting up our dot files and stuff like that. It's kind of sad to make that time investment and then we often can't use it because we have to work inside of a container. With Flox, the software that you've specifically asked for in your environment will always take precedence over whatever version you have locally, but it doesn't also remove all the software that's currently on your system, which is kind of the case with a container. Containers say, here's a sandbox, you no longer have access to anything on your system. With Flox, you keep your system, including tools and dotfiles, and you get to have your environment-specific software. You're also safe to experiment with an environment without having to worry about whether you've broken your system.

Drew: I saw somewhere that Flox is working on being able to generate a software bill of materials, which was interesting to me because I think that could be a really compelling feature in terms of adoption in the enterprise, where they would probably be excited to have more tools to address supply chain vulnerabilities. Can you tell me a little about that?

Zach: Yeah, for sure. You kind of hit the nail on the head. Enterprises definitely care about knowing what their vulnerability profile looks like. So, to explain this a bit, I mentioned before that every recipe in Nixpkgs is essentially a function from its dependencies to an artifact. Those dependencies aren't just the runtime dependencies, they're also the build time dependencies. So, every package that you get from Nixpkgs declares its set of inputs and those packages declare their inputs all the way down. With that structure, it becomes possible to enumerate all the transitive dependencies of software you’re using at runtime or build time. Once you have that list, it's not that much harder to go scan some vulnerability databases. So it's surprisingly easy.

Drew: We haven’t talked about Rust explicitly here. We’ve talked a lot about what you’ve been building with it. With that said, I'd be remiss if I didn't ask. So, how are you guys using Rust at Flox?

Zach: So, the command line tool, “flox”, is written in Rust. And, this is the tool that does all the user interaction. It’s the package manager. So you know, “flox install”, “flox uninstall”, “flox search”, and so on are all handled by Rust. It does all the activating of environments, pushing and pulling environments to FloxHub and such as well. We also have a small C++ executable that's written to interact directly with Nix. There were some early talks about possibly doing FFI, and there's a couple of reasons why we didn't do that. One is that Nix doesn't have a stable C interface. There's actually an experimental C API that's in a PR right now. I will also say it's been there for several months. So, who knows how that's going. I actually spoke at NixCon, basically showing what it was like to create a set of Rust bindings to Nix, either using the existing C++ code or using the experimental C API. Anyway, because there’s no C API and the C++ code isn't a stable interface either, you'd end up creating Rust bindings that were binding to a moving target. In the end, we just decided to do JSON RPC. It's much simpler and we control the interfaces.

Zach: There’s a lot that goes into choosing technologies. On the technical side, there are lots of boxes that have to be checked. Does Rust make it easy to do what you're trying to do? Does it have mature libraries for the kind of stuff you’re doing? On the social side, do the teams working on it know Rust or will you have to ramp them up? Do you have time for a ramp up? Also, is it easy to hire Rust engineers? Are they generally more expensive than a Python engineer for example? So yeah, we don't use Rust everywhere in the company, but we do use it for the part that users are going to use the most.

Drew: That's primarily what you work on, right, the Rust?

Zach: Yeah, I work on the Rust and the C++ part. I didn't know C++ before last October though.

Drew: Oh really?

Zach: Yeah. So now I know just enough to be dangerous. Even just last week, I lost a day to a bug that is very clearly documented C++ undefined behavior that I just wasn't aware of. I spend a lot more time debugging C++ than I do Rust, I'll say that. For the sake of avoiding language wars, I'll leave it there.

Drew: This was a really fun interview. Like I said, it was even a little bit selfish for me because it's an interesting problem space to me. Before we finish, is there anything else that you wanted to get into or wanted to mention?

Zach: Actually, yeah. We haven't talked about my favorite feature, which is the ability to layer environments. So, an example I use to demo this is a project that has a Rust backend and a React frontend. So, say I wanted to work on the backend, I can just “flox activate” a generic Rust environment. This particular project also uses the Diesel ORM, and there’s a set of tools that goes with Diesel. I can install those in a project-specific Flox environment and layer that with my generic Rust environment to keep those separated but also have the option to use them together. I can also create a frontend environment to handle that piece and layer that in as needed. So that's the ability to layer and compose different environments. And, of course you can also view environments on FloxHub.

Zach: What’s a practical application of this feature? At my previous company, there were just four of us on a team. Two of us were writing Rust and two of us were doing Python. The Python part was essentially a test harness that would run our service, provide us some inputs and see how it was working. Because of organizational decisions, the Rust and Python were both in the same repository and we could only have one Dockerfile. Both the Rust code and the Python code were under active development, so no matter which order you put them in the Dockerfile, we were rebuilding everything all the time. CI regularly took like 45 minutes, which is a nightmare. If they were using Flox, you'd have a Rust environment and a Python environment. When you wanted to change one or the other, you would just change that one, and it wouldn't affect the other one at all in terms of rebuilds or anything like that.

Zach: Another cool application is in bundling sets of tools. I have an environment that I created that I call “net_tools”. It has “curl”, “fx”, “httpie”, some DNS stuff, because it's always DNS (laughing). So that feature is a big deal for me.

Drew: Yeah, that's really cool. I can understand how being able to match the tool set to the natural context feels good. That’s also a big deal to be able to adjust sub environments within a project without rebuilding or reconfiguring the whole thing. Well thanks for chatting Zach!

Zach: Thank you!