What is your vision for the future technical direction of Nix?

[nyabinary]

Question

What is your vision for the future technical direction of Nix projects? What specific improvements or innovations do you believe should be prioritized to advance projects under Nix and address current challenges?

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

Please adhere to the Q&A guidelines and rules

[Gabriella439]

I've consistently advocated that Nix's path to mainstream adoption is using NixOS as a server OS, to the point where I even created a book about it.

I do think that it would be nice to improve Nix support for other use cases and I certainly won't stop volunteer contributors from doing what they want with their free time. However, there are areas where we do need to pick one use case to prioritize, like:

• Documentation

  One of the reasons people complain about the current state of our docs is because the docs are unopinionated and trying to cover too many different use cases. As a community we don't have a clear answer to "what application domain is Nix for?" and our documentation suffers because of that.

  For example, the current NixOS manual is geared mostly towards desktop users, but NixOS is (in my view) never going to be a mainstream desktop OS. I would support overhauling the manual to focus on the server-side deployment story and relegate the desktop-related documentation to a different resource (e.g. the NixOS wiki).

• Funding

  We should focus our funding efforts around building out a specific user experience for a target market and not spread our funding thin. It's better for one market get an exceptional end-to-end experience at the expense of other markets rather than to try to play the field and give everyone a half-baked experience. Targeting our efforts to produce a quality experience for one market will attract a cohort of mainstream adopters that will champion our ecosystem, give back to the community, and kick-start a virtuous cycle of mainstream adoption.

  Moreover, having a clear market that we cater to will make it easier to solicit funding from that companies within that market. Companies are more willing to fund open source projects if they feel confident the project direction and leadership is focused on their particular industry's needs and not distracted by other priorities.

• Language evolution

  Every new feature we add to the Nix language or the CLI increases the surface area that the entire community needs to support, whether that's documentation, IDE tooling, or bug fixing and maintenance. We want to make sure that any complexity we add to Nix is in service of building out a specific product vision and not pulling our ecosystem in yet another direction.

[mschwaig]

I am a researcher who is focused on supply chain security, and I see a lot of opportunities for Nix in that area.
You can find some of my views on that in this recent paper: https://cloud.ins.jku.at/index.php/s/txgoHps6FyNpiDk

But this is by no means the only technical topic and direction that I think is important.

I think in the Nix ecosystem we are really good at producing working prototypes for good technical ideas, but we are not as good at doing the work to polish them and make them the default user experience.
When I say this I'm thinking of the efforts around Trustix, IPFS, and Flakes.

I think we need to get better at finding good ways to integrate the results of those efforts, and deciding to make them part of the default user experience (or not).
I think this is where the SC can help, by giving direction and permission to existing efforts.

@Gabriella439 pointed out how unopinionated the manuals are, and I agree. I think direction by the SC could help there too.
For example, in my opinion, we should hide the commands for imperative package managment (with nix-env) in some dark corner of the manuals, not put them front and center.

[illustris]

My vision for the future technical direction of Nix projects involves expanding adoption by closely aligning development with the needs of users across various fields. As an SRE, I’ve seen how Nix can effectively replace traditional tools in areas like configuration management and infrastructure provisioning. For instance, Nix can supplant Dockerfiles, Puppet/Ansible, and even be used for writing Terraform configurations through tools like Terranix.

We need to understanding the specific requirements and challenges faced by professionals and enthusiasts in different domains. We should actively engage with end users to gather feedback and tailor Nix projects to better fit their workflows.

As for desktop users, there have been significant improvements in the last few years. The Calamares graphical installer for example greatly simplified the installation process. The next step is to develop intuitive graphical interfaces for modifying NixOS configurations and managing Nix packages. Such tools would lower the entry barrier for new users.

[tomberek]

"The purpose of the foundation is: to develop, propagate, and promote the adoption of a purely functional software deployment model..."
- https://github.com/NixOS/foundation/blob/master/by-laws/Oprichtingsakte_NixOsFoundation.en.pdf

My vision is for Nix (or some model similar to it) to be widely adopted and the standard for how software is managed. This makes it critical infrastructure and provides a net-benefit to mankind. This might seem bit hyperbolic, but I really do think that humanity would benefit as a whole. This means making Nix easier to use, understand, and adopt.

Specific technical innovations I am interested in are dynamic derivations, peer-to-peer caching, remote builds, using the Nix Store as a library, and relocatable stores. These would be foundational capabilities, but more important for adoption are things like clearer messaging of the benefits of Nix, improved usage at large scale, and simpler initial adoption by individuals.

[getchoo]

I would like to see an increase in documentation, automation, and encouraging purity in Nix projects

For documentation: We should continue supporting and growing official, user-facing documentation resources such as nix.dev and wiki.nixos.org, as well as internal contribution guides for developers in nixpkgs. These are cornerstones for the future growth and success of our community, and have already shown great potential in both onboarding new users and being useful to veterans alike. A good start here would be creating individual teams dedicated to these resources, that can then fall under a wider Documentation Team/Committee to organize and share things between them. Contributors should also be encouraged and assisted in regularly documenting new additions, even if it only serves as groundwork for the documentation teams to expand upon in the future

For automation: Contributors should first be encouraged to leverage our testing infrastructure using basic "smoke tests" such as testers.testVersion and testers.hasPkgConfigModules, all the way to full NixOS VM tests. This in turn will be useful in reducing the toil of package updates -- which should also be automated in more packages via passthru.updateScript. Finally, I would encourage the use and improvement of tools like https://github.com/nixos/nixpkgs-merge-bot that assist package maintainers in quickly landing changes, while not compromising the stability of nixpkgs

For purity: This overlaps with documentation a bit, but we should continue to push the avoidance of impurities in Nix -- specifically builtin fetchers, <...> search paths, and impure configuration of nixpkgs. These impurities can easily lead to losing one of the biggest advantages of Nix in reproducibility, and introduce the "works on my machine" issues we have worked so hard to avoid. Tools such as flakes and npins have done a lot in making this easier, and we should ensure they are the primary ways users want to create and consume Nix expressions

[roberth]

The community is already on a good trajectory; we have already started many good initiatives that improve the user experience and developer experience. Usually the problem is actually finishing such projects. This can be hard when everyone is half-responsible for too many things. This could be improved by encouraging contributors to limit themselves to fewer areas of interest and encouraging collaboration.

Over time I have documented many issues and proposals in GitHub issues for Nixpkgs and Nix. I'll list a few things that are on my mind, but more importantly, we should decide a roadmap together.

• Packages as a language level concept using derivation outputs instead of whole derivations
• Dynamic derivations (RFC 92) so we can stop adding lock files to Nixpkgs, and improve the granularity/incrementality of Nix builds, making Nix builds more suitable for development workflows (as @tomberek also suggests, Nix has great potential here and it should benefit everyone)
• Reduce the number of fixed points per package to resolve long standing tech debt, bugs and UX issues

However, more structural benefits will come from improving the development experience / contributor experience, testing and automation.

• Improve OfBorg to find tests more reliably for non-package changes such as modules
• Look into whether the build farm can be expanded (both OfBorg and Hydra)
• Improve the merge bot (e.g. something like meta.mergeCriteria so packages can opt in to fully automated updates)

[numinit]

I want to see Nix get more widespread adoption, because that will result in it being more successful. We should focus on how users are actually using things, and work on improving tech that facilitates that:

• Improve developer experience by stabilizing flakes. Try to get flake schemas out as part of this. Target Docker adjacent users so Nix feels less built for its developers, and more built to solve problems.
• Improve trust in the binary cache infrastructure by signing derivations in backwards compatible ways using hardware keystore keys, preferably with remote attestation of those keys.
• Improve the store situation by exploring distributed NAR fetching that helps with cache data egress cost as long as it doesn't also slow things down for people.
• Get rid of things people think are annoying, like cached eval errors. More automation, whenever we see something that's annoying to test by hand. Less nix- commands and more nix commands so there's one clear path to use things.

I love Nix, but also think that there's a huge wealth of technical improvements that will make others love Nix more. Let's focus on how people are actually using the software and iterate on it.

[proofconstruction]

Nix has been remarkably successful so far, without much or any cohesive vision, but I believe work must be done to gather ideas from the various projects being developed across the ecosystem - including unofficial projects - and synthesize these into a plan for the wide-scale development effort. Various teams currently labor in relative isolation from each other, but by coordinating their efforts and ideas we could surely go farther, faster. Articulating this plan and adhering us to it would be part of the mission of the Executive Directorate.

As I answered in #16, I believe pursuing 100% reproducibility is a very high priority, and would unlock a lot of other things downstream.

Beyond this, I only have one specific technical goal for Nix itself: to revisit the original idea and seriously consider a first-principles rewrite. It's my opinion that the early decision to build Nix in C++ (and Perl, and some other stuff) was a pragmatic and reasonable mistake, at least in the sense that much effort has been expended implementing features which are already present in languages better suited to the task (e.g. Haskell), which distracts from the core mission. The Nix we have today is large, complicated, and inflexible in ways that pose a serious concern, while the initial ideas were clean, simple, and beautiful. I believe we could achieve something much closer to the original concept, which would not only make the codebase easier to reason about but also make it more straightforward to onboard new contributors, ensuring Nix's continued success and maintainability, far into the future.

I would source other ideas for future technical direction from members of the community working on projects in various areas.