> You have the advantage that all existing production Nix code is known to terminate in short order

You don't really know this - there are many code paths in nixpkgs that are never touched during Hydra evaluation (various overrides, user-facing flags, packages marked broken and so on). We think it might be possible to slowly move towards more static analysis of the existing Nix language, but this is a little bit further down the road.

(Note by the way that we have a "runtime type checker" for Nix, but it is mostly an experiment: https://code.tvl.fyi/about/nix/yants)

It has all terminated in short order whenever and wherever executed, except possibly dodgy packages no one tries to install.

As sibling comments mention, this would struggle with edge-cases, and require too much buy-in from packagers.

A less ambitious approach would be creating/extending a static analyser/linter for Nix (there are already a few out there). This could nudge packagers towards certain styles, which language implementations could optimise for.

For example, an interpreter could have multiple implementations of the attrset interface (key/value mappings) with different performance characteristics, using some default for literals like '{ foo = "bar"; }' and a specialised version for known use-cases like nixpkgs.lib.nameValuePair ( https://github.com/NixOS/nixpkgs/blob/e9e53499b26ad98ac97f97... ) (mentioned in a sibling)

Linters could then spot when such functions are appropriate, e.g.

    Found literal name/value pair on line 123:
      { name = "x"; value = "y"; }
    This can be slow, consider using:
      nixpkgs.lib.nameValuePair "x" "y"'

> that existing Nix code could be translated into,

It is highly unlikely that this is feasible. I don't know nix in detail but I infer from your post that it is an untyped language. Untyped languages can, in general, not be translated to (statically decidable) typed languages.

> which could then be abandoned.

It could not, unless you convince a majority of the contributors to the package repo to switch to your new language.

> It is highly unlikely that this is feasible

Some more complex nix features would not be easy to transpile automatically, but many (i don't have stats sorry) packages are very simple declarations which could be ported automatically.

For example, all language-specific libraries imported from rust/python/etc could very easily be automatically ported, and in my experience, writing declarations for those many dependencies is what takes most time in making a small package (although admittedly i only tried once).

Nix, is a dynamically typed language, i.e. the language gives every value at runtime a type, but there a no compile-time (i.e. static) checks whether any function or operator calls will match at runtime to their parameters. Programs can be translated from dynamically typed-languages to statically typed languages. Either by infering types at translation time or by exhaustively adding lots of cases to every function or operator call depending on the runtime. The first approach can in principle only translate a subset of all programs, the latter does not give you any additional guarantees, because you have encoded an interpreter for the dynamically-type language into the statically typed language. Whether the first approach could be used on a large codebase like nixpkgs is highly questionable, the second approach would not yield any advantages here.

That's what I said in more words. I didn't mention the case of encoding the source language in the target because it should be obvious that this is, from the perspective of the translator, the trivial, and as you mention, useless, solution.