Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix Language Primer

binaryphile.com

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Nix Language Primer

#41

Post by [deleted] »

josteink wrote: post #18
microtonal wrote: post #16

Earlier quoted context omitted.

But then I had to use the Nix language. And that was a great displeasure, and I ended giving up NixOS all together because of this one pain point. Could you articulate why? I have only been using Nix for ~3 months, but so far I do not really have qualms with the Nix language. Maybe it is because I have written a fair bit of Haskell before. (Of course, I understand the argument that it would have been more comfortable…

> Could you articulate why? I have only been using Nix for ~3 months, but so far I do not really have qualms with the Nix language. I mean... It's not a "real" language in the sense that there exists any tooling, debuggers, unit-test suites or anything. You write your recipes and try to see if they work. And when they don't you have no idea why. With a real programming language (like Scheme) I could evaluate somethin…

[deleted]

Re: Nix Language Primer

#42

Post by zimbatm »

A few correction on the otherwise good article:

* Nix 2.0 includes the repl. Just run `nix repl`

* The URL literal returns a string

* It would be good to explain how the `` notation resolves paths from the NIX_PATH. For example `` looks for the `nixpkgs` key in `NIX_PATH=nixpkgs=/path/to/channel`

Re: Nix Language Primer

#43

Post by catern »

rekado wrote: post #29
catern wrote: post #4

Earlier quoted context omitted.

The Nix thesis may give some insight: https://nixos.org/~eelco/pubs/phd-thesis.pdf Guix's use of Guile is fundamentally equivalent to the Nix package manager's use of the Nix language, but the approach Guix takes to organizing packages is very different. IMO, the Nix language approach is cleaner and more elegant when it comes to describing packages, but it's not clear whether that's worth the cost of using a domain-s…

In Guix there are first class package objects that have references to other first class packages. Together they form a lazily evaluated graph. At a lower level, package objects can be compiled into one or many derivations, which is where things start to look more similar to Nix again. In Nix the idea of "functional package management" is more visible as there are no packages but functions with arguments that would re…

Yep, Guix package objects with references to other package objects, versus Nix functions with arguments, is what I was referring to.

Re: Nix Language Primer

#44

Post by adev_ »

k__ wrote: post #40
spacesuitman2 wrote: post #17

Why the need for another new language? Why not just use Guile or Scheme instead?

Probably the same reason why Guile or Scheme didn't get as wide-spread as other languages in general.

Because nobody want to program in (((( Guile )))), to the point that even GDB disable its support as extension language.

Re: Nix Language Primer

#46

Post by nwmcsween »

I don't understand why any languages exist for describing packages, its a layer above describing real dependencies like with make, ninja, etc. Just have an os written in something like premake but with a nicer DSL.

Re: Nix Language Primer

#47

Post by dorfsmay »

k__ wrote: post #40
spacesuitman2 wrote: post #17

Why the need for another new language? Why not just use Guile or Scheme instead?

Probably the same reason why Guile or Scheme didn't get as wide-spread as other languages in general.

And what would that be? Because it is lispy? Or because of the restrictive GNU licenses?

Re: Nix Language Primer

#48

Post by zimbatm »

rekado wrote: post #30
cwp wrote: post #5

Earlier quoted context omitted.

I think one of the keys features is lazy evaluation. Nixpkgs is one giant expression that evaluates to the complete set of packages that it provides. But since only some the attributes of that set are evaluated in any given invocation, it's still efficient. That can be vertical (eg, a package and it's dependencies) or horizontal (eg, the names of all the packages). Guix shows that this isn't the only way to do it, bu…

Guix packages are also evaluated lazily. Package objects (values of the ` ` type) can have an arbitrary number of declared inputs, which are package objects as well. These are not evaluated eagerly, of course. Lazy evaluation does not have to be a language feature. In the case of Guix's ` ` record, only some of the fields are delayed or thunked.

The difference is that the lazy evaluation needs to be baked in. There are many scenarios in the nixpkgs code-base where lazy evaluation is used on a not-package level. For example the NixOS module system depends heavily on it.

I haven't used Guix to be able to compare but it saved my life many times. I suspect the advantage for Guix is that it forces things to be better structured.

Re: Nix Language Primer

#49

Post by X6S1x6Okd1st »

otabdeveloper2 wrote: post #33
Harkins wrote: post #2

Does anyone know the rationale for creating Nixlang? Guix's use of Scheme proves there isn't a novel feature unavailable elsewhere, so it seems like a lot of wasted effort to implement a language that will likely only ever be used for one suite of programs. (And tooling; though almost none exists now, making the choice even more expensive.) I've tried to find one, but "nix" is a difficult thing to google for given th…

Nobody wants an arbitrary complex program for describing some trivial build steps. A programming language here is an anti-feature. Ideal would be some DSL that isn't even Turing complete, but that's not practical at the moment. Maybe we'll get there some day.

Really what no one wants is a build step that takes forever. I'm more upset about how long nix-env -i takes than what the computational complexity of the programming language is

Re: Nix Language Primer

#50

Post by lallysingh »

nwmcsween wrote: post #46

I don't understand why any languages exist for describing packages, its a layer above describing real dependencies like with make, ninja, etc. Just have an os written in something like premake but with a nicer DSL.

Make & ninja don't support two key activities:

- Versioning

- Getting the package (the actual URL, deciding if you want the package, determining which variant -- sometimes two packages solve the same dependency, etc.)

Post reply on HN