For error messages I think you're ultimately a bit cornered. Even typed languages have serious problems with straightforward and reliable errors, everything else aside. The ones that do tend to have to make careful tradeoffs in the system to achieve that (HKDs probably just straight up make error messages worse, for instance.) That said I think having types would be useful for helping navigate code, but I think you'd need a fairly advanced type system to capture all the "open ended" parts of Nixpkgs, and that's where all the value really is, the tons of little ways people have built up to use it over time. So it's a mixed bag. I sympathize though; I've spent a lot of time on spurious Nix bullshit, even if I still love the tools.
As a contributor I actually think that the success of projects like TypeScript have shown that there should be a way to build a type checker for something like Nix, with incremental migration. But it probably isn't going to be the ideal solution we could all imagine and it will be very very difficult nonetheless. But it could work with the code we have now, and that's a very important bar to clear (I don't take some of the other suggestions like "auto translate 30,000 packages to some other better language that doesn't exist & isn't the one people are using now" all too seriously, I'm afraid.)
I do think having a store implementation (even a "virtual one") decoupled from the evaluator and builder tooling is a step in the right direction for experimentation and hope that it works out.
Comments
For error messages I think you're ultimately a bit cornered. Even typed languages have serious problems with straightforward and reliable errors, everything else aside. The ones that do tend to have to make careful tradeoffs in the system to achieve that (HKDs probably just straight up make error messages worse, for instance.) That said I think having types would be useful for helping navigate code, but I think you'd need a fairly advanced type system to capture all the "open ended" parts of Nixpkgs, and that's where all the value really is, the tons of little ways people have built up to use it over time. So it's a mixed bag. I sympathize though; I've spent a lot of time on spurious Nix bullshit, even if I still love the tools.
As a contributor I actually think that the success of projects like TypeScript have shown that there should be a way to build a type checker for something like Nix, with incremental migration. But it probably isn't going to be the ideal solution we could all imagine and it will be very very difficult nonetheless. But it could work with the code we have now, and that's a very important bar to clear (I don't take some of the other suggestions like "auto translate 30,000 packages to some other better language that doesn't exist & isn't the one people are using now" all too seriously, I'm afraid.)
I do think having a store implementation (even a "virtual one") decoupled from the evaluator and builder tooling is a step in the right direction for experimentation and hope that it works out.