There have already been a few attempts at rewriting parts of, or all of Nix in Rust. While it is usually heavily discourage to completely rewrite a well established tool in a new language, I think there are a lot of idioms in Rust that map far more nicely to the concepts inherit in Nix than they do in C++, additionally, the current implementation leaves a lot to be desired, and refactoring the existing C++ would be difficult enough to feasibly justify such a rewrite after all.

That said, we also have tvix being worked on, which, at least according to the blog post, has been designed with a few desirable goals in mind, i.e. better performance, native IFD, etc. So it might be worthwhile to clarify what exactly are the goals of this project compared to others? Perhaps it is too early to care at this point, and that's a valid answer as well, but it'd be nice to know, from a potential contributors standpoint what the actual goals are.

A few questions off the top of my head, is this meant to be a serious replacement, just a toy project, an educational exercise, or useful as a core for other tooling (like an LSP)? If it is meant to be a full replacement someday, what are the key differentiating factors that would make this project worthwhile compared to Nix or Tvix? There are a lot of legacy design decisions in Nix that could really be improved if we establish these goals early enough, so I think, if this is meant to be a serious competitor in the long run, the sooner we clarify those goals, the better.

Hi, I've written https://github.com/zseri/nix-builtin-utils (when it hits a stable state I'd like to move it to the nix-community org, but it's not there yet...), which provides a C interface for the regex API which the original Nix implementation uses for builtin.match and builtin.split (look at the test suite for usage examples). These proved to be difficult when trying to transpile Nix to Javascript, and also when trying to implement it in Rust (otherwise I could've just compiled a rust impl to WASM, and get it done that way...) because most regex engines differ, so that they can cause subtle breakage...

Mentioning "0" would mean cargo would pick the latest dependency which is versioned "0.*" which would include versions incompatible with the one that this crate was written with and may break your create.

low hanging fruit ...

move build_math_fn to separate file?

lets rename built-in + to built-in add? (etc) - is used for subtraction and negation ! cannot be used in filenames

rename built_in to builtin? (like in nix)

        match (&*lhs, &*rhs) {
            (Value::String { parts: lhs_value }, Value::String { parts: rhs_value }) => {
                let mut new_value = LinkedList::<StringPart>::new();
                for val in lhs_value {
                    new_value.push_back(*val);
                    // error[E0507]: cannot move out of `*val` which is behind a shared reference
                    // move occurs because `*val` has type `StringPart`, which does not implement the `Copy` trait
                }
                for val in rhs_value {
                    new_value.push_back(*val);
                }
                Ok(Rc::new(Value::String { parts: new_value }))
            }

error[E0507]: cannot move out of `*val` which is behind a shared reference
   --> src/interpreter/runtime.rs:273:41
    |
273 |                     new_value.push_back(*val);
    |                                         ^^^^ move occurs because `*val` has type `StringPart`, which does not implement the `Copy` trait

implement copy trait in nixel?

in my case: nix develop will download 2GB of dependencies = killjoy nix-shell will download 10MB of dependencies

can we add a shell.nix file? (and call that from flake.nix)

{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
  buildInputs = with pkgs; [
    cargo
    cargo-tarpaulin
    clippy
    entr
    jq
    linuxPackages_latest.perf
    reuse
    rustc
  ];
}

Regarding store abstractions, it would be nice to know / extrapolate what exactly is necessary for the interpreter side to deal with stores. Thus, I want to sort-of collect stuff here which I think may be important (it if gets too off-topic, I'll move stuff to https://github.com/RIIR-Nix/rfcs instead) Also, the operations of the store can be split into three categories: Reading, Writing, Building. I think it might be a good idea to model this via multiple (maybe async) traits, especially because some stores don't support Writing (read-only) or Building (S3), e.g.

trait StoreRead { /* query store prefix, has hash path?, download hash path from store ... */ }
trait StoreWrite: StoreRead { /* upload hash path to store ... */ }
trait StoreBuild: StoreWrite { /* build derivation ... */ }

(derivation building is a bit weird, because the derivation function takes an attrset containing a pretty wild mix, and doesn't explicitly separate what ends up in the environment, what doesn't, might contain magic modifiers (__contentAddressed, __structuredAttrs,...), etc. (see also, somewhat generic abstraction of that))

Another question would be how to deal with store paths, store hashes and potentially content addressing, and the three different "types"/kinds of store paths/hashes:

• input addressed recursively based on input addressed only (this is usually the only type in classic non-CA Nix stores)
• input addressed with mixed (some CA-outputs as inputs) or no inputs)
• content addressed (these correspond roughly to the content-addressed derivation resolver in Nix; and leakage of placeholders in Nix when using content-addressed derivations sort-of proofs that this is a bit more difficult than expected)

Also, store paths have some sort of common format, which is useful when e.g. rewriting store paths in dumps or such (pretty much implemented here (although that store path format deviates a bit from the nix format, which is the reason why store_ref_scanner::StoreSpec exists))

Another thing to abstract are "store dumps" (e.g. deserialized NARs), e.g. something like https://github.com/YZITE/yzix/blob/cdd10d1249d6b6d8a79ed04d6acb01f92c932117/crates/yzix-core/src/dump.rs#L13-L17

pub enum Dump {
    Regular { executable: bool, contents: Vec<u8> },
    SymLink { target: Utf8PathBuf },
    Directory(std::collections::BTreeMap<crate::BaseName, Dump>),
}