This is a naive translation of the nix parser and evaluator to pure go.
This was done using Anthropic models.
The parser is a simple recursive descent thingy with pratt-parsing for operator precedence. Experiments on nixpkgs show about 1.3x nix parser.
The evaluator has nearly every builtin and can evaluate my system closure to create a hash-perfect .drv, so I’m reasonably certain this thing is correct for most use-cases. My system closure uses import-from-derivation (IfD) in places, so currently it asks the nix system daemon to realize stuff on the fly where needed (might be buggy).
My system closure evaluates in about 2x the time of C++ eval, of which half is spent on GC (completely unoptimized, this is a near 1:1 translation of C++ nix eval but hosted on the native golang GC instead of boehm). I’m pretty certain there’s some very low-hanging fruit here, so it should be possible to get within 1.5x easily by doing some smart object pooling or simple pprof stuff.
License is of course unchanged from lix, because there is not much original work here and all the actual footwork was done by Sonnet 4.6 and Opus 4.7. I’m pretty token efficient at doing this stuff so this took about 10–30 million tokens and roundabout 1 work week of my time.
Contact me (Fediverse or philip@decentsoftwa.re) if you think this is interesting or want to collab, my working thesis is that we can iterate fairly fast on new ideas in the nix ecosystem this way.
I have an initial (barely tested) translation of the sandbox code with a libseccomp-free pure go version of the seccomp rules, so doing the rest of this thing should be reasonably straightforward as well.
i think lix had spoken of gradually porting some bits to rust, to go at it the other way from snix/tvix.
that maybe raises the question for me then, could incumbent implementations similarly adopt bits of this if desired (without things getting too awkward)?
Sorry to be the killjoy here, but what exactly is useful about this software to make it worthy of an announcement? We live in times where anybody with a prompt and some money can convert anything into any language desired. As per your announcement, the new code fails on every relevant performance metric (except compile time, which I care little for, and maybe bootstrapping), and my personal experience with high-performance Go code does not inspire optimisim within me.
Especially with the “contact me ad”, this leaves a strong aftertaste of “abandonware performance stunt” rather than a piece of software with actual prospect of community adoption or collaboration
I am sorely tempted to respond in kind, which is the problem with language like this. I understand your frustration; you’re proud of the effort you’ve put into coercing this project into being, and you came here to show it off, not to defend your choice of process.
I don’t think you’re doing yourself or your project any favors by (mildly) antagonizing the people who are skeptical of that process. In the worst case, this announcement turns toxic and we have to hide it. Even in the best case, you breed unfriendly feelings among the people you might have reached without this barb. I wish you’d reconsider this language.
because I know this place is a toxic one (as obviously your answer is a good example of), I’d rather people contacted me personally so that I don’t have to interface with this community directly. Sorry to be so blunt.