4 ms·

I'm currently trying (and failing, lol) to switch to Nickel Nix. Nix OS/Pkgs is just amazing, but i'm near being entirely done with Nix Lang. Lazy + Dynamic is

I'm currently trying (and failing, lol) to switch to Nickel Nix. Nix OS/Pkgs is just amazing, but i'm near being entirely done with Nix Lang. Lazy + Dynamic is just a recipe for an awful developer experience. As far as i can tell no one (thus far) has been able to explain a reasonable and concrete way to tell what any given variable is within a Nix source file. `nix repl` works decently for some cases, but many not - since it seems to mostly help you inspect the output of a Nix expression. So hypothetically it could work, but for any given variable you'd have to recreate the entire value/function/etc stack that produced that value in that state. All around after ~16 months i think i'm finally done with Nix. It's Nickel or the highway for me. Not that i even love Nickel that much, but it's the bare bones of what Nix should have been in my view. Not sure if it's a hot take or not.. but it feels like you can have Lazy or Dynamic, but never both. The DX is terrible with both.

anon291 3y ago
What the nix language needs is support for first-class breakpoint instructions. That is, I ought to be able to do something along the lines of `let x = break (...)` The semantics here is that, when x is evaluated (i.e., forced into WHNF), I get placed into a debugger where I can examine the context and either (1) choose to return a new value for `x` or (2) let it fall through and let `x` take on the value of `(...)`. The main issue with nix is debuggability
- aliasxneo 3y ago
  Yes, anyone who has spent any serious amount of time maintaining Nix code has felt this pain. I also have come to dislike the Nix language, but it was the daily debugging that eventually drove me away. In my case, it was for production systems, and there's nothing more agonizing then having to debug a Nix stack trace on a deadline.
- unshavedyak 3y ago
  Agreed, though i prefer types to solve this - but i imagine what you suggest would even benefit a typed language like Nickel. Really would be a useful inspection tool. Nix is just a massive blob of difficult to debug code. Really awful experience for me.
- takeda 3y ago
  looks like that was added last year: https://github.com/NixOS/nix/blob/4a880c3cc085841a1537040405bc142fefffd7ff/doc/manual/src/release-notes/rl-2.9.md?plain=1#L3 https://github.com/NixOS/nix/blob/4a880c3cc085841a1537040405... https://www.zknotes.com/note/5970 https://www.zknotes.com/note/5970
ochoseis 3y ago
I tend to agree. I was trying to follow the guide on how to install NixOS with root-on-zfs[0]. I’ve followed it before with my own tweaks just fine, but recently it was updated to include some random guy’s modules that automate a couple steps. They’re mostly shallow abstractions on first-party NixOS modules, but following it was such a pain. I’ve been putting off reverse engineering the guy’s code so I can understand exactly what it’s doing. Apart from the code quality, it would probably be a lot easier to see what was going on in a typed language, with a debugger. Hopefully one day it gets there. [0]: https://openzfs.github.io/openzfs-docs/Getting%20Started/NixOS/index.html https://openzfs.github.io/openzfs-docs/Getting%20Started/Nix...
- kaba0 3y ago
  What module do you mean? I didn’t find it in your link.
  - ochoseis 3y ago
    The repo in step one of this sub-page: https://openzfs.github.io/openzfs-docs/Getting%20Started/NixOS/Root%20on%20ZFS.html#system-configuration https://openzfs.github.io/openzfs-docs/Getting%20Started/Nix...
- SkyMarshal 3y ago
  I've been using root on ZFS for two years, but without using a specific module for it. Some info and links here: https://www.reddit.com/r/NixOS/comments/ops0n0/big_shoutout_to_the_nixos_team_for_the_excellent/ https://www.reddit.com/r/NixOS/comments/ops0n0/big_shoutout_...
yjftsjthsd-h 3y ago
For building packages, don't you kind of need it to be lazy? I don't want to compile and install all of nixpkgs.
- unshavedyak 3y ago
  Depends, i imagine like most things - the answer is nuanced, or at the very least depends on the specific other decisions. For example, i don't see why a configuration would install actual packages - if that's what you mean. Besides, i am not advocating against lazy by itself. I'm just saying that something which is both lazy and untyped is a huge PITA. Nickel adds typing, validation, etc - information, by which you can still have Lazy and a better DX by way of types. At least in theory, i've not used it much. My biggest gripe is dynamic Nix, fwiw.
- yencabulator 3y ago
  When you're programming in any old non-lazy language, your functions don't get automatically called, it's only when you put that call in code that's being executed. If you don't mention a thing in your main, that thing has no reason to get executed. Nix is lazy because the whole point of the original work was "what if package management, but FP". The resulting /nix/store etc system has very little to do with FP and is, in fact, built by imperative bash scripts.
kaba0 3y ago
> has been able to explain a reasonable and concrete way to tell what any given variable is within a Nix source file That’s the problem with the anemic and ad hoc libraries nixpkgs uses, not the language. There is a magic buildWhateverXPackage function that needs some magic attributes and you are done. The problem is that there is no interface to aid in how that should be used - but it is the same way in JavaScript as well. Also, you are writing a description of something, it won’t be a traditional program with an event loop or whatnot - here lazyness does make sense.
von_lohengramm 3y ago
> As far as i can tell no one (thus far) has been able to explain a reasonable and concrete way to tell what any given variable is within a Nix source file. `nix repl` works decently for some cases, but many not - since it seems to mostly help you inspect the output of a Nix expression. So hypothetically it could work, but for any given variable you'd have to recreate the entire value/function/etc stack that produced that value in that state. It's certainly not ergonomic, but from what I can tell so far, `builtins.trace` and `builtins.traceVerbose` are about as good as it's gonna get. It quite literally lets you inspect any arbitrary Nix expression, but it's just such a friggin' hassle to wrap things with it & reevaluate just to do what literally any real debugger can do in two keystrokes. > All around after ~16 months i think i'm finally done with Nix. It's Nickel or the highway for me. Not that i even love Nickel that much, but it's the bare bones of what Nix should have been in my view. I'm curious. Have you messed around with Dhall? It's suspiciously similar to Nickel (even mentioned on their site), but it's been around longer so it's probably a bit more viable to actually make your config in Dhall. Dhall or Nickel, it'll still insanely janky and more trouble than it's worth. Personally, I've found that what's worked surprisingly well for me is just really focusing on building a good understanding of the Nix language in an effort to avoid needing to debug as much as possible. "Just don't write bugs" as the saying goes. I've been using Nix for a while, and I'm still loath to debug it.
- unshavedyak 3y ago
  I have not tried Dhall, i should give it a look. Currently i'm exploring transpiling to Nix or possibly type annoations inside Nix. I just need something where the time investment in researching Nix types and sources can actually be reused, rather than forgotten. edit: ooo, looks like someone made a similar program with Dhall. https://www.haskellforall.com/2017/01/typed-nix-programming-using-dhall.html https://www.haskellforall.com/2017/01/typed-nix-programming-...
takeda 3y ago
Have you tried https://github.com/nickel-lang/nickel-nix https://github.com/nickel-lang/nickel-nix ? I didn't use it yet, but looks like this supposed to do it.
- unshavedyak 3y ago
  I've been trying today, looks to be very incomplete. Eventually it may work, but sounds like not now. I'm now exploring transpiling to Nix lol. I'm moderately dedicated in my distaste of Nix hah.

anon291 3y ago

What the nix language needs is support for first-class breakpoint instructions. That is, I ought to be able to do something along the lines of `let x = break (...)` The semantics here is that, when x is evaluated (i.e., forced into WHNF), I get placed into a debugger where I can examine the context and either (1) choose to return a new value for `x` or (2) let it fall through and let `x` take on the value of `(...)`. The main issue with nix is debuggability

aliasxneo 3y ago
Yes, anyone who has spent any serious amount of time maintaining Nix code has felt this pain. I also have come to dislike the Nix language, but it was the daily debugging that eventually drove me away. In my case, it was for production systems, and there's nothing more agonizing then having to debug a Nix stack trace on a deadline.
unshavedyak 3y ago
Agreed, though i prefer types to solve this - but i imagine what you suggest would even benefit a typed language like Nickel. Really would be a useful inspection tool. Nix is just a massive blob of difficult to debug code. Really awful experience for me.
takeda 3y ago
looks like that was added last year: https://github.com/NixOS/nix/blob/4a880c3cc085841a1537040405bc142fefffd7ff/doc/manual/src/release-notes/rl-2.9.md?plain=1#L3 https://github.com/NixOS/nix/blob/4a880c3cc085841a1537040405... https://www.zknotes.com/note/5970 https://www.zknotes.com/note/5970

ochoseis 3y ago

I tend to agree. I was trying to follow the guide on how to install NixOS with root-on-zfs[0]. I’ve followed it before with my own tweaks just fine, but recently it was updated to include some random guy’s modules that automate a couple steps. They’re mostly shallow abstractions on first-party NixOS modules, but following it was such a pain. I’ve been putting off reverse engineering the guy’s code so I can understand exactly what it’s doing. Apart from the code quality, it would probably be a lot easier to see what was going on in a typed language, with a debugger. Hopefully one day it gets there. [0]: https://openzfs.github.io/openzfs-docs/Getting%20Started/NixOS/index.html https://openzfs.github.io/openzfs-docs/Getting%20Started/Nix...

kaba0 3y ago
What module do you mean? I didn’t find it in your link.
- ochoseis 3y ago
  The repo in step one of this sub-page: https://openzfs.github.io/openzfs-docs/Getting%20Started/NixOS/Root%20on%20ZFS.html#system-configuration https://openzfs.github.io/openzfs-docs/Getting%20Started/Nix...
SkyMarshal 3y ago
I've been using root on ZFS for two years, but without using a specific module for it. Some info and links here: https://www.reddit.com/r/NixOS/comments/ops0n0/big_shoutout_to_the_nixos_team_for_the_excellent/ https://www.reddit.com/r/NixOS/comments/ops0n0/big_shoutout_...

yjftsjthsd-h 3y ago

For building packages, don't you kind of need it to be lazy? I don't want to compile and install all of nixpkgs.

unshavedyak 3y ago
Depends, i imagine like most things - the answer is nuanced, or at the very least depends on the specific other decisions. For example, i don't see why a configuration would install actual packages - if that's what you mean. Besides, i am not advocating against lazy by itself. I'm just saying that something which is both lazy and untyped is a huge PITA. Nickel adds typing, validation, etc - information, by which you can still have Lazy and a better DX by way of types. At least in theory, i've not used it much. My biggest gripe is dynamic Nix, fwiw.
yencabulator 3y ago
When you're programming in any old non-lazy language, your functions don't get automatically called, it's only when you put that call in code that's being executed. If you don't mention a thing in your main, that thing has no reason to get executed. Nix is lazy because the whole point of the original work was "what if package management, but FP". The resulting /nix/store etc system has very little to do with FP and is, in fact, built by imperative bash scripts.

kaba0 3y ago

> has been able to explain a reasonable and concrete way to tell what any given variable is within a Nix source file That’s the problem with the anemic and ad hoc libraries nixpkgs uses, not the language. There is a magic buildWhateverXPackage function that needs some magic attributes and you are done. The problem is that there is no interface to aid in how that should be used - but it is the same way in JavaScript as well. Also, you are writing a description of something, it won’t be a traditional program with an event loop or whatnot - here lazyness does make sense.

von_lohengramm 3y ago

> As far as i can tell no one (thus far) has been able to explain a reasonable and concrete way to tell what any given variable is within a Nix source file. `nix repl` works decently for some cases, but many not - since it seems to mostly help you inspect the output of a Nix expression. So hypothetically it could work, but for any given variable you'd have to recreate the entire value/function/etc stack that produced that value in that state. It's certainly not ergonomic, but from what I can tell so far, `builtins.trace` and `builtins.traceVerbose` are about as good as it's gonna get. It quite literally lets you inspect any arbitrary Nix expression, but it's just such a friggin' hassle to wrap things with it & reevaluate just to do what literally any real debugger can do in two keystrokes. > All around after ~16 months i think i'm finally done with Nix. It's Nickel or the highway for me. Not that i even love Nickel that much, but it's the bare bones of what Nix should have been in my view. I'm curious. Have you messed around with Dhall? It's suspiciously similar to Nickel (even mentioned on their site), but it's been around longer so it's probably a bit more viable to actually make your config in Dhall. Dhall or Nickel, it'll still insanely janky and more trouble than it's worth. Personally, I've found that what's worked surprisingly well for me is just really focusing on building a good understanding of the Nix language in an effort to avoid needing to debug as much as possible. "Just don't write bugs" as the saying goes. I've been using Nix for a while, and I'm still loath to debug it.

unshavedyak 3y ago
I have not tried Dhall, i should give it a look. Currently i'm exploring transpiling to Nix or possibly type annoations inside Nix. I just need something where the time investment in researching Nix types and sources can actually be reused, rather than forgotten. edit: ooo, looks like someone made a similar program with Dhall. https://www.haskellforall.com/2017/01/typed-nix-programming-using-dhall.html https://www.haskellforall.com/2017/01/typed-nix-programming-...

takeda 3y ago

Have you tried https://github.com/nickel-lang/nickel-nix https://github.com/nickel-lang/nickel-nix ? I didn't use it yet, but looks like this supposed to do it.

unshavedyak 3y ago
I've been trying today, looks to be very incomplete. Eventually it may work, but sounds like not now. I'm now exploring transpiling to Nix lol. I'm moderately dedicated in my distaste of Nix hah.