We want to make Nix better

Nix is immensely powerful but it can have quite the steep learning curve. Numerous people in our industry hotly desire what Nix has to offer: hermetic development environments, fully reproducible package builds, declaratively configured operating systems. But even those who are aware of Nix’s benefits know that actually using Nix to solve real problems has some jagged edges. The Nix expression language is a bit odd coming from most other languages, the core concepts aren’t always super digestible, the package manager is unlike apt, deb, Homebrew and the rest—all in all, it’s just a different paradigm of doing things that requires a substantial investment of time and energy.

At Determinate Systems, we love Nix, but to those who don’t love it enough to make that investment: we hear you. Many folks in software engineering, even some seasoned Nix veterans, feel that Nix’s sterling feature set often comes at too high a cost. It’s straightforward enough to convince your team or your boss that Nix could have a transformative impact, but convincing people to commit the resources to adopt Nix is another matter. Other tools and approaches may be good enough to get the job done well enough and call it a day; best to stick with a just-okay but known quantity. For those who are passionate about Nix, this can be a tough pill to swallow.

Our mission

We’re confident that we can break this impasse. Our objective at Determinate Systems is to enable people across the software world to reap the many benefits of Nix without nearly as much effort—and occasional pain—as Nix has demanded in the past. In some cases, that will mean that we improve the experience of using Nix itself by contributing to the Nix ecosystem. But in other cases it will mean giving users access to Nix’s wonderful features without requiring them to use it directly, letting Nix quietly do its vital work in the background while exposing few if any internals.

We love Nix because it solves a wide range of problems with aplomb. Those who have used it directly—to build a package, to configure a NixOS system, to create a development environment—have a keen sense of its power. But we know that it isn’t reasonable to make learning and struggling with Nix a condition of benefiting from it. All programming languages and paradigms require an investment, but Nix is meant to facilitate software development, not be the center of attention. It’s supposed to help you write, distribute, and deploy Rust, Go, Python, JavaScript, and others. Helping those who have already invested in Nix is a significant part of our mission—but so is helping those who want a better way to ship software without taking on a new learning project.

A representative problem

Let’s make this more concrete by talking about a specific problem that we’re currently looking into: the problem of external dependencies. These are dependencies that are written in a different language from the one you’re currently developing in. Some examples: the Protobuf compiler, protoc, is a problem in Rust projects because it’s written in C++; Nokogiri is a problem in Ruby projects because it’s written in C; and [OpenSSL] presents a problem in all kinds of languages. Ideally we’d all be able to git clone and cd into any software project and immediately start building and testing, but we all know the experience of Googling and StackOverflowing just to get off the ground.

Fortunately, the external dependency problem already has a solution: Nix! You can use Nix to configure a shell environment with all the necessary dependencies installed. A Python project that requires OpenSSL? No problem. A Haskell project that requires Asciidoc? No problem. Need to share those environments across teams and port them to your continuous integration system? No problem.

But there’s a catch: to make that happen you need to write some Nix, use Nix tools, and probably consult several documentation sources. If you’re already using Nix to solve external dependency problems, great! You’re in good company. But this is the kind of problem we want to solve for people who don’t have the bandwidth or the desire to learn Nix.

Where we go from here

The external dependency problem is far from alone. It’s part of a vast constellation of interrelated problems that make developing, distributing, and deploying software much more brittle, complicated, and resource intensive than they should be. In Nix, we as an industry have the tool to take an enormous chunk out of these kinds of problems. At Determinate Systems, we’re committed to being a major driving force behind this. We’ll have some specific—and exciting—announcements about our approach to the external dependency problem—amongst others— soon, so stay tuned here on our blog, in the DeterminateSystems GitHub organization, and on Twitter.