121–130 of 204 posts
Earlier quoted context omitted.
> This is why Nix is really just a front for bash. For all of its faults, at least bash is Turing-complete. Nix is Turing-complete. This was even sometimes considered a problem because it makes the language too powerful: https://nixos.org/~eelco/talks/guix-feb-2018.pdf
This is news to me, I admit. But if this is true, then people shouldn't say Nix is declarative.
Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…
Nah. The logical conclusion of this is that Nix should be some Java-like, Python-like, or whatever else qualifies as something that the average developer knows.
Nix needs to be declarative which rules out the average PL paradigm.
> […] , but can the next iteration provide an on-ramp which doesn't involve learning a new lang and paradigm? Guix folks sure think so.
Does the average developer know Scheme? I think you just played yourself.
Earlier quoted context omitted.
> However, when more power is necessary, it is required; it is not possible, by the definition of Turing-completeness and declarative, to do the same thing with a declarative language that can be done with a Turing-complete language. So when that power is missing, the only option is to work around it. I fall heavily into the use less powerful languages and "liberties constrain, constraints liberate" camps. I'd be ver…
> I fall heavily into the use less powerful languages "liberties constrain, constraints liberate" camp. For what it's worth, so do I. That's why my build system will allow users to set those constraints. It's a great idea. > I'd be very interested in a real world example of this, though I know that class of examples is hard to come by. There are many, but I'll say one: anything that requires iteration until a fixed p…
Earlier quoted context omitted.
> I fall heavily into the use less powerful languages "liberties constrain, constraints liberate" camp. For what it's worth, so do I. That's why my build system will allow users to set those constraints. It's a great idea. > I'd be very interested in a real world example of this, though I know that class of examples is hard to come by. There are many, but I'll say one: anything that requires iteration until a fixed p…
Would you consider lisp to be (possibly) declarative?
Earlier quoted context omitted.
Would you consider lisp to be (possibly) declarative?
No, it is Turing-complete. I was going off of the article and Nix documentation that says Nix is declarative. But if it actually is not, then there shouldn't be a problem with power. However, Nix proponents shouldn't claim it is declarative either.
Disclaimer: I'm working on a build system that will eventually do what Nix does but make it much easier to use. If they do manage to create a system where Nix is hidden, and end users never have to directly touch it, I think this could work and make my work never see the light of day. But I have my doubts that they will be able to do that, and it boils down to one simple reason: declarative is not powerful enough. Do…
Nix is turing complete (it can implement the Lambda Calculus), even conveniently so.
Earlier quoted context omitted.
One of Nix's benefits is it aims to isolate where programs are installed; so you can have multiple versions of the same program available without conflict. (e.g. programs built with different feature flags, or multiple minor versions). Nix achieves this by storing packages in a path as some hash of its inputs. -- This then allows either compiling or downloading a package, with confidence that it will behave the same…
But, since the files were under /nix, if you put them under /opt, then you wouldn't be able to make use of the compilation caches for /nix. Until a very short time ago there was no binary cache for Apple Silicon Macs.
Earlier quoted context omitted.
On Linux, users can put their Nix store in their home directory or other places and at run-time Nix remaps the directory using user namespaces. Unfortunately this isn't workable on macOS: the kernel doesn't support the features we need. Using /nix and a separate group and daemon means the store can be read-only and be protected from modification in several ways. This is pretty helpful, as a lot of tools try very hard…
It would be less palatable when I found out. The group is fine. Why the daemon when other package managers use sudo is unclear. Even Homebrew moved to /opt.
Nix is a package manager, yes, but it's more than that, it's a generalized build system.
Earlier quoted context omitted.
It would be less palatable when I found out. The group is fine. Why the daemon when other package managers use sudo is unclear. Even Homebrew moved to /opt.
Other package managers are okay with requiring sudo because they install stuff globally. Nix doesn't have that restriction, you can use it for local stuff, temporary shell environments, etc. So you need non-admin users to be able to use it too, and even admin users need to be able to use it without using sudo. For example, when entering a nix shell, you don't want the shell to run as root. Or when using direnv. Or ju…
Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…
Having used Nix a bunch, the system has been hard to use and learn in exactly the same ways that messy legacy codebases I've worked with have been hard—which makes sense since Nixpkgs is an absolutely massive codebase that's evolved over the years with very distributed development. People latch onto the Nix language and the paradigm because that's the most tangible difference but, everything else held equal, Nix + Ni…
The same thing we do for other paradigms (system architecture, programming concepts, etc.) - find and document common patterns, then find ways to transition to the patterns away from things out of pattern, and lastly introduce automatic refactorings that do fix these things in bulk.
I definitely agree with you on the evolution thing. Homebrew is a similar DSL for installing packages on macOS. It has the problem where things get deprecated from the DSLs (Casks and Formulae) which leads to not being able to run various commands until previously installed software is fixed.