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

We want to make Nix better

determinate.systems

Post reply on HN
Print view View original

101–110 of 204 posts

Re: We want to make Nix better

#101

Post by pseudalopex »

grhmc wrote: post #14
qudat wrote: post #9

Earlier quoted context omitted.

Yikes, I had no idea. What a tough pill to swallow all because the directory nix runs out of is hardcoded.

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.

Re: We want to make Nix better

#102

Post by vdijkbas »

gavinhoward wrote: post #66

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…

> 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

Re: We want to make Nix better

#103

Post by rnhmjoj »

vamega wrote: post #12
qudat wrote: post #9

Earlier quoted context omitted.

Yikes, I had no idea. What a tough pill to swallow all because the directory nix runs out of is hardcoded.

It's not hardcoded, but you end can't take advantage of the binary caches if you change the directory. A company could certainly create their own binary cache and distribute that to it's users.

Not entirely true, there are many ways in which you can use a custom location and still take advantage of the binary cache. You can do it with chroot, file system namespaces, bind mounts and so on. There's also a nice user friendly tool that does exactly this [1].

[1]: https://github.com/DavHau/nix-portable

Re: We want to make Nix better

#104

Post by amelius »

Jeaye wrote: post #15

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…

Also: it should be able to deal with NVidia cards.

Re: We want to make Nix better

#105

Post by ontouchstart »

I have more than 20 years of Unix experience and was getting into DevOps and CI/CD in the recent years with GitHub Actions, Azure DevOps, AWS etc. I literally discovered Nix yesterday via Andrew Kelley’s Zig demo on YouTube. I had the similar feeling as I first learned Unix tool chains two decades ago.

I believe live demo and CI/CD pipeline might be some of the best use cases to get people interested in Determinate Systems. Don’t get distracted by language features and syntactic sugars. If it works, people will learn.

Re: We want to make Nix better

#106

Post by lykahb »

The name Nix is used for the language, package system, and sometimes the whole ecosystem. There is a recent post that tells the difference https://www.haskellforall.com/2022/08/stop-calling-everythin...

Knowing functional programming helps but Nix still is a hard language to learn. I have a lot of Haskell experience but the Nix language was very confusing for me. At first I couldn't even tell a variable name from a keyword (it is a convention to call variables "self" and "super" in some contexts). The Nix language has been created for research in build systems and has evolved over a long time, so it has accumulated quite a lot of idiosyncrasies and cruft.

I hope that a simpler typed language like https://github.com/tweag/nickel replaces it.

Re: We want to make Nix better

#107

Post by JustLurking2022 »

ontouchstart wrote: post #105

I have more than 20 years of Unix experience and was getting into DevOps and CI/CD in the recent years with GitHub Actions, Azure DevOps, AWS etc. I literally discovered Nix yesterday via Andrew Kelley’s Zig demo on YouTube. I had the similar feeling as I first learned Unix tool chains two decades ago. I believe live demo and CI/CD pipeline might be some of the best use cases to get people interested in Determinate S…

I've worked with large scale monorepos in FAANG - as a rule, they all suck. Eventually you always end up in this place where you have to understand, and be prepared to debug the entire universe just to build hello world.

Re: We want to make Nix better

#108

Post by flurie »

grhmc wrote: post #2

With Eelco as a cofounder of DetSys, I feel really excited about where we're going here. I think the world is in many ways primed and ready for Nix, as long as we can help Nix "meet them in the middle." We're working on making Nix more accessible and producing good and usable, production-ready workflows so teams can just pick it up and go. I'd love to hear what y'all think, to help make sure we're going in the right…

Hi, Graham, I have a few questions.

Does Eelco's departure from Tweag have any impact on Nickel as a possible replacement for nix?

There are lots of fragmented attempts at making nix easier/more immediately valuable/lower barrier to entry. Some of these are personal projects, some are businesses. Some of these just make nix easier, and some attempt to put something in between nix and the user. I'm thinking about things like Cachix, Flox, and divnix (formerly devos). How do you see your work interacting with these?

One of my barriers to adoption at work has been ensuring maintenance continuity. That's always going to be the case for tools that aren't ubiquitous, but I worry with nix that teams without my assistance will revert to other tools they know better, even if I've invested a good bit of time in teaching them enough to keep things going. Do you seek to address that?

Re: We want to make Nix better

#109

Post by HowTheStoryEnds »

ghoward wrote: post #76
ParetoOptimal wrote: post #68

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…

Would you consider lisp to be (possibly) declarative?

Re: We want to make Nix better

#110

Post by ghoward »

nonsequitur wrote: post #95
gavinhoward wrote: post #66

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.

Then people shouldn't say it is, such as in the article under discussion.
Post reply on HN