If you have left or are leaving #Nix / #NixOS, would you be willing to move to a fork?

(Please consider sharing to help increase the sample size)

No
20%
Yes as a user
55.2%
Yes as a maintainer
24.8%
Poll ended at .

In a single day, sourced only from fedi, 268 people have committed to migrating to a fork. 184 as users and 84 as contributors maintaining packages. This is a very good starting point for a #NixPkgs fork (which includes #NixOS).

The biggest blocker remaining is #Nix itself. Securing maintainers for Nix (the cpp project) would mean a newly established fork can exist independently. If you would be able to do so, please get in touch.

@jakehamilton idk how good any of them are but there are some reimplementations of nix in rust (and even haskell lol)
@jakehamilton I think #tvix has the best chance of taking CppNix’s place here. You will be drawing from a different pool of contributors, at least. I’m 100x more interested in diving into TVL’s code base than looking at CppNix again, just because it’s in rust, and that’s my preference
@brk if the project is nix-compatible and ready to be used then I think it would work. Last I checked Tvix still says it is very unstable and shouldn't be used in production yet. If that has changed and any rustaceans can commit to maintaining it then we can move on from nix.
@jakehamilton @brk I would be extremely interested in tvix and willing to maintain it if it was ready…if it wasn’t so anti-flakes
@cafkafk @jakehamilton @brk flakes are a must have honestly
@cafkafk @jakehamilton @brk For what it's worth, you don't need for tvix be super stable from day one. For one, any fork should probably not cut a stable release on day one, and there is also no real reason to use Nix to get bootstrapped until tvix us more usable.
The imo most important feature of flakes, stable inputs, can be stapled on with pure nix code, so not necessarily a deal breaker either

@jakehamilton The main problem is that I don't think C++ is a good choice for maintainability. It's good for bootstrapping, which is why Eelco chose it initially, but I think we can do better with a nixpkgs-bootstrapped codebase written in a nicer high-level language intended for compilers.

That said, I am begrudgingly available to read C++ and do code reviews if nobody else volunteers.

@corbin @jakehamilton "which is why Eelco chose it initially" - it's easy to forget, but Nix was created in 2003, predating even git. There weren't exactly many alternatives on the market back then.

@Valodim @jakehamilton Yes, a great point. The nicest tools available at the time were perhaps OCaml and Haskell 98, and the latter wouldn't have performed well enough. Fortunately, we now have nicer tools.

Right now I'm experimenting with RPython, the toolkit used to build PyPy. It wasn't usable until 2007, and the JIT backend I'm using wasn't written until 2009: https://rpython.readthedocs.io/en/latest/jit/pyjitpl5.html But today it is a robust and reliable way to write an interpreter in Python 2.7 and get a native JIT compiler. Unlike OCaml, metaprogramming is builtin by default, and memory management is available even for FFI, so the amount of required interpreter code is fairly small.

PyJitPl5 — RPython Documentation

@jakehamilton #nixpkgs is also the part with need forking the least as Eelco didn't contribute much to it anyways. The problems were all in #cppnix so the community should focus on forking it
@docRekd what about the social and governance problems of nix projects?
@jakehamilton I don’t have the time or resources to start it up myself, but I’d love to help maintain and develop a CppNix fork as part of a larger team. I don’t love C++, but I’ve always wanted to get involved with the Nix evaluator and put my functional programming experience to good use. there’s also lots of features and initiatives I’d love to help work on that wouldn’t be possible with the current CppNix team.