4 ms·

There are noble goals to this project to rewriting Nix to improve performance. The reasons feel valid. However I wonder about certain issues: - Nix itself has

There are noble goals to this project to rewriting Nix to improve performance. The reasons feel valid. However I wonder about certain issues: - Nix itself has problems of compatibility with Nix! Let me explain...recently NixOS 21.11 released. It still comes packaged with Nix 2.3.16 instead of Nix 2.4 because of incompatibility issues. When the Nix project itself is not able to deliver backwards compatibility I feel uncertain that Tvix might be able to deliver their promise of full compatibility with all the deep architectural changes it plans. Nix does not have a formal specification: Nix is what its C/C++ implementation says. Nix also has deep architectural changes planned going ahead. So Tvix will need to re-architect Nix keeping in mind (and keeping up) with the future changes that are coming. It's going to be tough to build this "alternative" implementation. Users are going to run into weird compatibility issues, not have the patience to resolve them and then just go back to the original Nix implementation. - A rewrite to a popular project will find it difficult to succeed. There is simply too much momentum in the parent Nix implementation (I'm not talking about the package definitions here) that very few people are likely to adopt this rewrite. This is because most people might not really need the speedup. However, it's possible that the pain around slow evaluation runs so deep that other companies might adopt this too. I don't know enough here. - The rewrite needs to offer more reason to shift. Right now this rewrite seems to be mainly about performance. There is also a proposal to be able to integrate with GNU Guile. To me this is just avoiding one untyped language (Nix) to replace with another slightly better untyped language (Guile Scheme) (GNU Guix uses Guile also AFAIK). What about introducing typing? https://github.com/tweag/nickel https://github.com/tweag/nickel is an interesting project and it would be great to have a system like Nix with optional typing to make writing the derivations more robust. What about rewriting in a safe programming language (e.g. Rust or a GC-ed language)? These things would be likely to excite would-be-contributors and would make your rewrite viable. In other words, the rewrite needs to offer more than just the promise of performance. Perhaps I have not understood the project goals fully. Maybe the project is all about just being able to leverage the Nix package definitions but have a totally different implementation to instantiate them? But the issue here is that nix-the-language is very intimately tied up with the nix-the-platform and the rewritten implementation will still need to really be extremely compatible to capture all the implicit assumptions in nixpkgs. Once again, improving nix through a rewrite is a noble goal. It's a tough problem and it would be awesome if the project succeeds! I have obviously not thought about this as much as you guys and would love to learn how you wish to tackle some of these problems. Maybe some of these issues are not as big as them seem??

chme 5y ago
I would also like it if the language itself can be decoupled from the build and package manager system, so that it can be embedded in other software that would benefit from a language like nix. I think that might be a worthy goal and could attract people outside of the nix sphere.
- axelf4 5y ago
  Have you looked at Dhall? I do not think Nix the language would ever be preferable when compared to already existing configuration languages.
  - tazjin 5y ago
    Nix is a much older language than Dhall, this seems like a weird argument to me.
    - pxc 5y ago
      Dhall was inspired by Nix, and created by a longtime Nixer. Also as someone who likes simple FP but is not some sophisticated typelevel programmer, Dhall looks really complicated and verbose. To me, the Nickel approach, where authors of libraries in the language (equivalent to things like nixpkgs.lib) can pepper their functions with type annotations, but users can use what looks and feels like a simple configuration language, seems like a better approach for the domain. I can't imagine getting all of the PHP developers I support comfortable editing the equivalent of shell.nix in Dhall themselves. Nix files I can ask them to edit without taking up too much of their time or focus.
- tazjin 5y ago
  Yep, we'd like that, too! Our current thinking around the evaluator design incorporates the idea of evaluation with/without a Nix store, where using the language itself (e.g. to generate JSON structures or whatever) should be perfectly possible without a store.
- southerntofu 5y ago

chme 5y ago

I would also like it if the language itself can be decoupled from the build and package manager system, so that it can be embedded in other software that would benefit from a language like nix. I think that might be a worthy goal and could attract people outside of the nix sphere.

axelf4 5y ago
Have you looked at Dhall? I do not think Nix the language would ever be preferable when compared to already existing configuration languages.
- tazjin 5y ago
  Nix is a much older language than Dhall, this seems like a weird argument to me.
  - pxc 5y ago
    Dhall was inspired by Nix, and created by a longtime Nixer. Also as someone who likes simple FP but is not some sophisticated typelevel programmer, Dhall looks really complicated and verbose. To me, the Nickel approach, where authors of libraries in the language (equivalent to things like nixpkgs.lib) can pepper their functions with type annotations, but users can use what looks and feels like a simple configuration language, seems like a better approach for the domain. I can't imagine getting all of the PHP developers I support comfortable editing the equivalent of shell.nix in Dhall themselves. Nix files I can ask them to edit without taking up too much of their time or focus.
tazjin 5y ago
Yep, we'd like that, too! Our current thinking around the evaluator design incorporates the idea of evaluation with/without a Nix store, where using the language itself (e.g. to generate JSON structures or whatever) should be perfectly possible without a store.
southerntofu 5y ago