6 ms·

I would also like it if the language itself can be decoupled from the build and package manager system, so that it can be embedded in other software that would

by chme 5y ago

I would also like it if the language itself can be decoupled from the build and package manager system, so that it can be embedded in other software that would benefit from a language like nix. I think that might be a worthy goal and could attract people outside of the nix sphere.

axelf4 5y ago
Have you looked at Dhall? I do not think Nix the language would ever be preferable when compared to already existing configuration languages.
- tazjin 5y ago
  Nix is a much older language than Dhall, this seems like a weird argument to me.
  - pxc 5y ago
    Dhall was inspired by Nix, and created by a longtime Nixer. Also as someone who likes simple FP but is not some sophisticated typelevel programmer, Dhall looks really complicated and verbose. To me, the Nickel approach, where authors of libraries in the language (equivalent to things like nixpkgs.lib) can pepper their functions with type annotations, but users can use what looks and feels like a simple configuration language, seems like a better approach for the domain. I can't imagine getting all of the PHP developers I support comfortable editing the equivalent of shell.nix in Dhall themselves. Nix files I can ask them to edit without taking up too much of their time or focus.
tazjin 5y ago
Yep, we'd like that, too! Our current thinking around the evaluator design incorporates the idea of evaluation with/without a Nix store, where using the language itself (e.g. to generate JSON structures or whatever) should be perfectly possible without a store.
southerntofu 5y ago
> I would also like it if the language itself can be decoupled from the build and package manager system I would also like that, but for the exact opposing reason. I love the concepts of nix/guix but i can't stand the dynamic languages with cryptic error messages.
- KingMachiavelli 5y ago
  It is a pain but it is manageable with practice. Also the error messages on Nix 2.4 are a lot better and can show the location of errors which is enough 90% of the time.
  - southerntofu 5y ago
    Can't wait to try out nix 2.4 then, whenever it's deemed compatible with NixOS.
    - KingMachiavelli 5y ago
      It has been released. The 20.11 release contains both a nix_2_3 and a nix_2_4 package. I'm fairly certain the only reason 20.11 defaults to 2.3 is because the development of 2.4 focused a lot on flakes despite the fact that there are still an 'experimental' feature (experimental like Gmail was a beta for 7+ years). If you aren't using Nix already there is no reason you can't just start using 2.4 with flakes enabled.
      - southerntofu 5y ago
        Some other comments in this thread (i have no idea how true they are) suggested there were serious backwards-incompatibilities preventing nix2.4 from being default in the last NixOS release.
    - pxc 5y ago
      Nix 2.4 is totally compatible with NixOS. It was held back from default status on the latest NixOS release because it includes a few behavior changes to the CLI that have been jarring for some users. It's to ease the transition for them, not because it's broken or something like that. You can set up Nix 2.4 on NixOS 21.11 by adding nix.package = pkgs.nix_2_4; in your configuration.nix :) I like the new CLI, too, and it's worth trying if you want to see what all is new in Nix. Here's how to enable flakes on NixOS, if you have Nix 2.4: nix.extraOptions = '' experimental-features = nix-command flakes '';

by chme 5y ago

axelf4 5y ago

Have you looked at Dhall? I do not think Nix the language would ever be preferable when compared to already existing configuration languages.

tazjin 5y ago
Nix is a much older language than Dhall, this seems like a weird argument to me.
- pxc 5y ago
  Dhall was inspired by Nix, and created by a longtime Nixer. Also as someone who likes simple FP but is not some sophisticated typelevel programmer, Dhall looks really complicated and verbose. To me, the Nickel approach, where authors of libraries in the language (equivalent to things like nixpkgs.lib) can pepper their functions with type annotations, but users can use what looks and feels like a simple configuration language, seems like a better approach for the domain. I can't imagine getting all of the PHP developers I support comfortable editing the equivalent of shell.nix in Dhall themselves. Nix files I can ask them to edit without taking up too much of their time or focus.

tazjin 5y ago

Yep, we'd like that, too! Our current thinking around the evaluator design incorporates the idea of evaluation with/without a Nix store, where using the language itself (e.g. to generate JSON structures or whatever) should be perfectly possible without a store.

southerntofu 5y ago

> I would also like it if the language itself can be decoupled from the build and package manager system I would also like that, but for the exact opposing reason. I love the concepts of nix/guix but i can't stand the dynamic languages with cryptic error messages.

KingMachiavelli 5y ago
It is a pain but it is manageable with practice. Also the error messages on Nix 2.4 are a lot better and can show the location of errors which is enough 90% of the time.
- southerntofu 5y ago
  Can't wait to try out nix 2.4 then, whenever it's deemed compatible with NixOS.
  - KingMachiavelli 5y ago
    It has been released. The 20.11 release contains both a nix_2_3 and a nix_2_4 package. I'm fairly certain the only reason 20.11 defaults to 2.3 is because the development of 2.4 focused a lot on flakes despite the fact that there are still an 'experimental' feature (experimental like Gmail was a beta for 7+ years). If you aren't using Nix already there is no reason you can't just start using 2.4 with flakes enabled.
    - southerntofu 5y ago
      Some other comments in this thread (i have no idea how true they are) suggested there were serious backwards-incompatibilities preventing nix2.4 from being default in the last NixOS release.
  - pxc 5y ago
    Nix 2.4 is totally compatible with NixOS. It was held back from default status on the latest NixOS release because it includes a few behavior changes to the CLI that have been jarring for some users. It's to ease the transition for them, not because it's broken or something like that. You can set up Nix 2.4 on NixOS 21.11 by adding nix.package = pkgs.nix_2_4; in your configuration.nix :) I like the new CLI, too, and it's worth trying if you want to see what all is new in Nix. Here's how to enable flakes on NixOS, if you have Nix 2.4: nix.extraOptions = '' experimental-features = nix-command flakes '';