Industrial users of Nix for compiled languages?

Hi all,

I'm doing some research to understand the existing or desired use cases
of Nix for compiled-language development in industry. If your company
uses, or has seriously considered using, Nix for your development
environments or builds of a project you develop in a compiled language,
and you or someone at that company is willing to have a quick call or
email exchange to help me get a handle on your successes, pain points,
and wish lists, please let me know! I can be reached easiest at



I’ve been trying to use it at a small java shop working with spark and data analytics, most of my troubles have been around getting it to work with maven. Will reach out when I have some bandwidth!

A lot of people don’t take into consideration how much effort was given to make a particular environment work with a given toolchain.

That said, your mileage will vary greatly for different toolchains. If you use good c/c++ practices with normal autotools/cmake/qmake conventions, it should be pretty easy. And it should be relatively easy on most compile languages. But I’ve also seen many code bases where they are full of hacks; and it will be painful to try and introduce nix, which is very heavy on purity.


I use Nix to isolate development environments for some projects, and by far the biggest pain points are channels and the absence of version info as first-class package metadata. Right now, I can easily say in my project’s default.nix that I rely on, e.g.: blas, boost, gsl, and icu for a C++ project. I cannot specify the versions I want without having to muck with old channels, dealing with packages which include versions in their names in some weird way, and generally getting a huge headache.

I don’t necessarily expect every single binary to be available for download along with every single one of its dependencies. Some caching would be great, of course, but even triggering a recompile of an old package version is really hard right now.


as long the derivation’s build steps didn’t alter significantly, you should be able to do package.overrideAttrs and set the version and source to be the version you need.

at least for boost, nixpkgs keeps onto each version

$ nix-build -A boost
boost          boost160       boost165       boost169       boost17x
boost155       boost162       boost166       boost16x       boost-build
boost159       boost163       boost167       boost170       boost_process
boost15x       boost164       boost168       boost171

similar for icu

$ nix-build -A icu
icu    icu58  icu59  icu60  icu63  icu64

and theres a v1 for gsl

$ nix-build -A gsl
gsl    gsl_1