4 ms·
(author here) I agree that Nix not being statically typed is one of the biggest drawbacks of the language. Having it statically typed with a strong type system
by rkrzr 6y ago
(author here) I agree that Nix not being statically typed is one of the biggest drawbacks of the language. Having it statically typed with a strong type system like Haskell's would help solve some of the readability issues that you mention. Types of course also serve as documentation, which is another often-mentioned weak point of the language.
Finally, with static types we could also have much better editor support with nice things like auto-completion.
Unfortunately, I'm not aware of any efforts to add (optional) typing to the Nix language.
- throwaway894345 6y agoI think [Nickel][1] aims to add static types to Nix, but I don't know of any efforts to integrate Nickel into nixpkgs. [1]: https://github.com/tweag/nickel https://github.com/tweag/nickel
- jonringer117 6y agoIt's still in development. But swapping a language is possible, as it's only needed for evaluation. Building the package (realization) just needs the derivation.
- camehere3saydis 6y agoSo does that mean I can just hack together my own derivations in, say, Python, and bypass the whole nix-shell vs. nix-env, overlays vs overrides, home-manager, flakes, etc. menagerie? And use only Nix only for its central artifact store and dependency resolution? It kind of looks like they're trying out different interfaces to the same basic core functionality and seeing what catches. My personal gripe is that wrappers for languages that have their own package managers are abysmal. But griping about Nix on HN is just extra publicity. Now we're just waiting for someone to explain it in a sufficiently succinct way for the crowd. Come to think of it, that's kind of like Monads in Haskell a few years back. Anyone remember the series of watered down explanations that failed to address the actual problem people were having, which was that that people were confused by the notation, if I recall correctly. Nix's roots are close to Haskell turf, so it comes as no surprise they're struggling with explaining their abstractions, resulting in the series of mutually overlapping "official" ways to do things (none of which, incidentally, is the "obvious" way if there is one). After all, Nix is a build tool and not a whole language, so they get to try different CLIs and config APIs within with less overhead than experimenting with a language's syntax.
- deleted 6y ago[deleted]