in my over a decade of using nix i have never really managed to get into using the repl because every time i have it's been … weird in some way or another
alexandrutocar
Exactly my thoughts. You can even go as far as `nix eval .#<attr> --json --apply <expr>` to transform whatever your flake outputs list into your desired format and then presenting it as JSON. Then you can consume the JSON and process it with a language of your choice. Or you can extend the standard library with your own primitives, types and tricks and do whatever you want to do in Nix. The switch to other language is worth only if processing that you are doing becomes too slow or too clunky in Nix - both are subjective, so I personally do the processing in Nix and export it only if I want AI in the loop e.g. giving my packages and services as context to siff through changelogs of flake updates to make summaries with information relevant to my systems.
skavi
aren’t there also nix lsps
tom_alexander
Yep! Personally I use nixd but there are multiple nix lsps. There are definitely places where nixd stops helping due to nix being a dynamically-typed language. For example, when writing functions it doesn't know what the types of any of the parameters are because they could be literally anything. That being said, the example from the screenshot of typing `pkgs.neo` and getting a list of completions for package names absolutely works with nixd.
gavinray
> "Nix is lazy, so the emitted code wraps an expression in nix.thunk(() => ...)"
Why not use Generator functions rather than manually wrapping everything?
On-demand value materialization is what Generators are for
easygenes
Please at least add "(Nix transpliled to typescript)" to the title so it's clear what we get.
lorecoeur
Funnily enough, it might very well be a morale failure. Just not a moral one.
boredatoms
Is there a nix-language learning book out there? Last I looked it was pretty difficult to get learning material
isityettime
Not a book (you don't really need a whole book for such a small language!), but this is the classic resource: https://nixcloud.io/tour/
Then the things you need to learn in order to read and understand most Nix code is just the stdlib, which is most convenient to browse here: https://noogle.dev/
Beyond that, it's all just conventions that are covered well by reference material. So those two are all you need in order to find your footing when it comes to the Nix language.
(For a tutorial overview of the whole ecosystem, nix.dev is the best entrypoint. For the build system or an introduction to some of the basic "internals", you want The Nix Pills. And in general, the best thing of all to read when it comes to Nix is Nixpkgs itself. :)
Umm, does a Nixfile have a "grammar" of a 140000+ records and 232000 attributes from its individual packages? Can a lightweight text editor underline an error?
peter_d_sherman
Excellent article!
Heck, not just an excellent article, an exceptional one!
This is why I read HN -- to find articles like this one!
The basic problem:
Everybody loves Software! Software, specifically having a huge breadth and variety for a given platform is the key to that platform's success! (Just ask Bill Gates of Microsoft that, about Windows!) Well a lot of Open Source software is on GitHub, but one problem is (or rather was!) that it needed to get built for a whole bunch of platforms... Simple right? Well, not so much for the average user who is not a programmer when there are numerous types of CPU (x86, ARM, RISC-V, etc., etc.), numerous OS platforms, numerous compilers and compiler versions, and (usually) other dependencies on specific versions of other Open Source software packages...
So who could solve this chaotic "wild west" of exponential build combinations?
Well, historically, GNU autotools (aclocal, autoconf, autoheader, automake, autoreconf, autoscan, gnu m4, libtool, etc., which created files such as: aclocal.m4, config.h, config.h.in, config.log, config.status, configure, Makefile, Makefile.in, etc.) tried to solve this problem, and for the most part did so -- but usually only for users who were familiar with using Unix/Linux command-line tools and usually only for GNU compilers, and build processes which had dependencies on other projects or libraries could break rather spectacularly if the exact correct version of those projects or libraries that the base software was dependent on was not known, or not selected correctly.
What was needed was something more generic, and yet more precise.
Which is the basis for the Nix functional programming language, NixPkgs and NixOS.
Basically, all problems in software deployment (i.e., configuring and building software correctly from source) could be solved if there was the following:
Immutability in Storage: Once a software component is built, it is stored in a centralized location (the Nix Store, typically /nix/store) and marked as strictly read-only. Components are never modified in place.
Purity of the Build Process: Build actions are treated as mathematical functions. A build process is strictly isolated and hermetic—it is stripped of access to external environment variables or network resources, ensuring that the exact same inputs will always produce the exact same cryptographic output.
Well, turns out Eelco Dolstra and Nix / NixOS were right!
Why? Because now there are over 140,000 Open Source software packages in NixPkgs, i.e., installable by the Nix Package Manager. That's more than any other Linux package collection. And the breadth of combinations of CPU's, Platforms, OS'es, etc., far surpasses the build options of any other Linux distro's package collection!
But that's the next problem, and that's the problem this article so brilliantly addresses -- which is, if all of that software ecosystem, all of those build scripts are ultimately tied to Nix language, and the Nix language is hard to understand / hard to modify for newcomers to it, then how to unbind that entire software ecosystem from the Nix language?
And the answer (or at least one answer!) is what this article author suggests, which is "hey, let's convert the Nix language to Typescript"!
And this is (one great!) solution to the following problem:
>"Anyone who wants to explore the store-model space from a different direction, a new language, a new evaluator, a new editor experience, must then start from zero packages. This is the graveyard where other reimplementations or forks of Nix go to die."
On-demand value materialization is what Generators are for
Then the things you need to learn in order to read and understand most Nix code is just the stdlib, which is most convenient to browse here: https://noogle.dev/
Beyond that, it's all just conventions that are covered well by reference material. So those two are all you need in order to find your footing when it comes to the Nix language.
(For a tutorial overview of the whole ecosystem, nix.dev is the best entrypoint. For the build system or an introduction to some of the basic "internals", you want The Nix Pills. And in general, the best thing of all to read when it comes to Nix is Nixpkgs itself. :)
Heck, not just an excellent article, an exceptional one!
This is why I read HN -- to find articles like this one!
The basic problem:
Everybody loves Software! Software, specifically having a huge breadth and variety for a given platform is the key to that platform's success! (Just ask Bill Gates of Microsoft that, about Windows!) Well a lot of Open Source software is on GitHub, but one problem is (or rather was!) that it needed to get built for a whole bunch of platforms... Simple right? Well, not so much for the average user who is not a programmer when there are numerous types of CPU (x86, ARM, RISC-V, etc., etc.), numerous OS platforms, numerous compilers and compiler versions, and (usually) other dependencies on specific versions of other Open Source software packages...
So who could solve this chaotic "wild west" of exponential build combinations?
Well, historically, GNU autotools (aclocal, autoconf, autoheader, automake, autoreconf, autoscan, gnu m4, libtool, etc., which created files such as: aclocal.m4, config.h, config.h.in, config.log, config.status, configure, Makefile, Makefile.in, etc.) tried to solve this problem, and for the most part did so -- but usually only for users who were familiar with using Unix/Linux command-line tools and usually only for GNU compilers, and build processes which had dependencies on other projects or libraries could break rather spectacularly if the exact correct version of those projects or libraries that the base software was dependent on was not known, or not selected correctly.
What was needed was something more generic, and yet more precise.
Enter Eelco Dolstra, and his Ph.D. thesis "The Purely Functional Software Deployment Model": https://edolstra.github.io/pubs/phd-thesis.pdf
Which is the basis for the Nix functional programming language, NixPkgs and NixOS.
Basically, all problems in software deployment (i.e., configuring and building software correctly from source) could be solved if there was the following:
Immutability in Storage: Once a software component is built, it is stored in a centralized location (the Nix Store, typically /nix/store) and marked as strictly read-only. Components are never modified in place.
Purity of the Build Process: Build actions are treated as mathematical functions. A build process is strictly isolated and hermetic—it is stripped of access to external environment variables or network resources, ensuring that the exact same inputs will always produce the exact same cryptographic output.
Well, turns out Eelco Dolstra and Nix / NixOS were right!
Why? Because now there are over 140,000 Open Source software packages in NixPkgs, i.e., installable by the Nix Package Manager. That's more than any other Linux package collection. And the breadth of combinations of CPU's, Platforms, OS'es, etc., far surpasses the build options of any other Linux distro's package collection!
But that's the next problem, and that's the problem this article so brilliantly addresses -- which is, if all of that software ecosystem, all of those build scripts are ultimately tied to Nix language, and the Nix language is hard to understand / hard to modify for newcomers to it, then how to unbind that entire software ecosystem from the Nix language?
And the answer (or at least one answer!) is what this article author suggests, which is "hey, let's convert the Nix language to Typescript"!
And this is (one great!) solution to the following problem:
>"Anyone who wants to explore the store-model space from a different direction, a new language, a new evaluator, a new editor experience, must then start from zero packages. This is the graveyard where other reimplementations or forks of Nix go to die."
Well not anymore!
Anyway, a truly brilliant article!