Is NixOS a scheme? Anyway, we moved away from Nix because of all its problems (the language being only a medium-sized one). Also, I detest CMake, but by your own standard (longevity, popularity), it is better than Nix or Guix. Frankly those tools haven’t shown themselves to be “superior” in any meaningful way. Yes, they have been around for a while, but having been around for a long time and not enjoying any significant adoption is not very compelling.
That question does not make any sense. I am talking about Scheme the programming language: https://schemers.org/
NixOS is a GNU/Linux distribution built on top of the Nix package manager. The Nix package manager has its own custom configuration language. GuixSD is a GNU/Linux distribution built on top of the Guix package manager. GuixSD uses Guile Scheme as the package configuration language, system configuration language, scripting language, and implementation language for many of the system services (such as init). GuixSD does more things better with an existing standard programming language than NixOS does with its own custom programming language.
> Also, I detest CMake, but by your own standard (longevity, popularity), it is better than Nix or Guix.
What does CMake have to do with anything?
> Yes, they have been around for a while
What are you talking about? The first stable version of NixOS, 13.10, was released in 2013. GuixSD 1.0 was only released this May.
Yeah, I misunderstood your post—sorry about that. I thought you said “Guix and Nix show us that scheme is the answer”. In any case, I don’t know how you conclude that Guix won over Nix nor how you conclude that the winner is superior to all other configuration languages. It’s especially counter-intuitive that it should be an intermediate representation—the IR should not be executable, it should only be descriptive. The IaC technology shouldn’t need to interpret anything, and the language you pass into it therefore shouldn’t support evaluation/execution.
> I don’t know how you conclude that Guix won over Nix
There is no contest that I am aware of. I used GuixSD vs NixOS as an example of how adapting existing standards can provide a lot more benefits with a lot less effort than coming up with incompatible new languages.
> how you conclude that the winner is superior to all other configuration languages
Here is a condensed list:
1. 60+ years of successful use of S-expressions in all of the needed roles (programming language, intermediate representation, configuration language, template language, network protocols).
2. Many proven Scheme implementations available for use in any scenario, from clusters to microcontrollers.
3. Easily amenable to formal analysis and verification. Excellent tools such as ACL2 available and in use for many decades.
> It’s especially counter-intuitive that it should be an intermediate representation—the IR should not be executable, it should only be descriptive.
S-expressions do both.
> The IaC technology shouldn’t need to interpret anything, and the language you pass into it therefore shouldn’t support evaluation/execution.
That is an unexpected thing to say about an acronym that stands for "Infrastructure as Code." You cannot get automation out of static data.
I don’t find that list very compelling. Longevity in particular isn’t very interesting given that Scheme has gained very little ground in 60 years. That seems like an indicator that there is something wrong. I would sooner use Python or JavaScript, which are familiar to programmers in general and which have gained lots of traction in their respective lifetimes.
> S-expressions do both.
Right, that’s the problem. :)
> That is an unexpected thing to say about an acronym that stands for "Infrastructure as Code." You cannot get automation out of static data.
It’s a matter of architecture and separation of responsibilities. The IaC technology takes static data and automated the creation, mutation, and deletion of the resources specified therein. The client generates that flat data by evaluating a program over some inputs.
