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."
> Ask nixpkgs a question in a loop. Interrogate and explore nixpkgs in a REPL
Is there a nix-language learning book out there? Last I looked it was pretty difficult to get learning material
nix.dev is generally pretty solid. Check out their tutorial for the Nix lang: https://nix.dev/tutorials/nix-language
Please at least add "(Nix transpliled to typescript)" to the title so it's clear what we get.
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.
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!
Funnily enough, it might very well be a morale failure. Just not a moral one.
See also: https://github.com/glistix/glistix