Jake HamiltonIf 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
Yes as a user
Yes as a maintainer
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.
Corbin@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.
Vincent Breitmoser@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.