3 ms·

Nix is a full programming language, just a really idiosyncratic one with syntax only a mother could love. I've been using lisp for over 20 years now and would

Nix is a full programming language, just a really idiosyncratic one with syntax only a mother could love. I've been using lisp for over 20 years now and would much prefer if guile replaced the nix language (or Common Lisp, if I can dream), but I still use NixOS for practical reasons.

georgyo 3y ago
I don't mind the nix language, and I far prefer it to lisp. But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations. It would be able to use stuff from nixpkgs as well, at least partially anyway. The built derivations are an extremely simple format anything can produce.
- aidenn0 3y ago
  If I understand correctly, Guix can do this. Of course the derivation is the final output, so you lose all of the nix modules and nix packages, which kind of defeats the purpose of using NixOS.
  - georgyo 3y ago
    I don't think you nessairly need to give up interop. Kinda like his JavaScript can call wasm modules. The compiler would need to know how to use nixpkgs, but the user could write their derivations any way they see fit.
    - aidenn0 3y ago
      You can depend on other derivations rather easily, but interoperating with functions written in the nix language is more challenging. (And without nix language interop, basically all of NixOS that isn't nixpkgs is useless).
- pxc 3y ago
  > But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations This is originally how Guix worked— it generated .drv files in the same format as Nix and then asked a Nix daemon to build them. But both projects consider the derivation format an implementation detail that should be free for them to change according to the needs of the rest of the stack, rather than a stable interface for downstream consumers (be they end users or other software tools). The above is not just theoretical— as a result, the derivation formats of the two projects have diverged. (Tbh I agree with their position, though. I don't think the concept of the derivation should really be visible to end users. The way the term is used is extremely overloaded/ambiguous, and so at the end of the day it's jargon that serves more to obscure than to teach.)
hardwaresofton 3y ago
what are these practical reasons -- ecosystem size? tooling/documentation?
- aidenn0 3y ago
  ecosystem size and less friction for non-free software.

georgyo 3y ago

I don't mind the nix language, and I far prefer it to lisp. But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations. It would be able to use stuff from nixpkgs as well, at least partially anyway. The built derivations are an extremely simple format anything can produce.

aidenn0 3y ago
If I understand correctly, Guix can do this. Of course the derivation is the final output, so you lose all of the nix modules and nix packages, which kind of defeats the purpose of using NixOS.
- georgyo 3y ago
  I don't think you nessairly need to give up interop. Kinda like his JavaScript can call wasm modules. The compiler would need to know how to use nixpkgs, but the user could write their derivations any way they see fit.
  - aidenn0 3y ago
    You can depend on other derivations rather easily, but interoperating with functions written in the nix language is more challenging. (And without nix language interop, basically all of NixOS that isn't nixpkgs is useless).
pxc 3y ago
> But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations This is originally how Guix worked— it generated .drv files in the same format as Nix and then asked a Nix daemon to build them. But both projects consider the derivation format an implementation detail that should be free for them to change according to the needs of the rest of the stack, rather than a stable interface for downstream consumers (be they end users or other software tools). The above is not just theoretical— as a result, the derivation formats of the two projects have diverged. (Tbh I agree with their position, though. I don't think the concept of the derivation should really be visible to end users. The way the term is used is extremely overloaded/ambiguous, and so at the end of the day it's jargon that serves more to obscure than to teach.)

hardwaresofton 3y ago

what are these practical reasons -- ecosystem size? tooling/documentation?

aidenn0 3y ago
ecosystem size and less friction for non-free software.