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

191–200 of 204 posts

Re: We want to make Nix better

#191

Post by zuzuleinen »

emptysongglass wrote: post #161
zuzuleinen wrote: post #26

"But there’s a catch: to make that happen you need to write some Nix, use Nix tools, and probably consult several documentation sources." You can use bob[1] if you want a build tool which uses Nix to install dependencies in an easy manner: just list the package names for a task and then they will be installed. I'm looking forward for all the changes in Nix ecosystem and it's a good sign the fact that they also starte…

Is Bob complementary to Devbox recently featured in a Show HN here and would you be willing to explain how you might use both together if so?

I think they only way in which they are similar is the way a user would add dependencies for a project. If with devbox a user populates devbox.json with package names, with bob you add dependencies in list inside bob.yaml. You can find out more in a short guide[0] I wrote.

But bob intends to be more than a dependency manager, it wants to be fully-fledged build system similar to Dagger, Bazel, Earthly etc with features like:

* build pipelines[1]. You can define and manage your build pipelines in a familiar YAML format. You also get caching for your targets and so on.

* isolated environment. We completely clear the environment for a task. I see with devbox that if I do a `printenv` or an `echo PATH` while I'm still in an active devbox shell, I see variables from my local system which can affect reproducibility.

* workspaces: manage multi-repo setups in an easy manner

[0] https://bob.build/docs/usage/package-management

[1] https://bob.build/docs/usage/build

Re: We want to make Nix better

#192

Post by mongol »

a1369209993 wrote: post #154
tikhonj wrote: post #85

Earlier quoted context omitted.

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…

> People rarely jump I'd just like to take a moment to reiterate that object-oriented programming is a mistake produced by cargo-culting half a dozen different styles used by competent programmers (including the devolpers of smalltalk and its relatives, from which OOP appropiated its name), and that Java is completely unusable by anyone with a sense of self-respect and a awareness that programming languages can be be…

If it would be unusuable it would not have been used to do so many useful things. By all means, there may be better options out there but it is far from as bad as you describe it.

Re: We want to make Nix better

#193

Post by tazjin »

kaba0 wrote: post #187
tazjin wrote: post #63

Earlier quoted context omitted.

Some community members have looked into this quite a bit, and personally I have come to the conclusion that types don't really give that much benefit to Nix (and I say this as a Rust & Haskell developer). Nix expressions are almost always[2] short-lived snippets that evaluate to a data structure, not long-running programs where the distinction between "static analysis time" and runtime is extremely relevant. In fact,…

I am originally opposed to blaming the Nix language, but now that I read your comment and thought a bit more about it, Clojure’s spec might be a much better tool than types. It would solve the readable error messages problem quite well and is flexible enough to accommodate any usage like parameter passing.

Something like Clojure's spec would IMO be a better fit, yeah. I've written an experiment with a runtime type-spec and checker for Nix: https://code.tvl.fyi/about/nix/yants/README.md

However, this has massive runtime cost (especially in hot code paths), so some sort of spec-like annotation system would be cool. We'll see how it shakes out over time ...

As for error messages, we might already be able to do big improvements in Tvix. Our bytecode has pretty exact tracking of the source spans that things come from all the way throughout, so we could trace things like a type error being raised somewhere to the last time that value was passed through as a function argument from user code etc.

This error message business will be a whole area of development of its own however, for now we're just making sure that as much of the relevant information is available as cheaply as possible.

Re: We want to make Nix better

#194

Post by amelius »

WastingMyTime89 wrote: post #175
amelius wrote: post #118

Earlier quoted context omitted.

Ok, that is good to know. But how well does it run on NVidia's Jetson line of systems? https://developer.nvidia.com/embedded-computing

The Jetson environment provided by Nvidia runs Ubuntu and are setup for you to use docker. I have trouble understanding your question. Why do you want to use Nix if you use a system which comes pre-configured to do something else?

Same reason why I removed Windows from my desktop computer and installed Linux :)

Re: We want to make Nix better

#195

Post by ghoward »

grumbel wrote: post #182
ghoward wrote: post #111

Earlier quoted context omitted.

This is news to me, I admit. But if this is true, then people shouldn't say Nix is declarative.

This shouldn't really come as a surprise, any reasonably powerful language will end up Turing complete sooner or later, it's pretty difficult to avoid. Nix specifically doesn't even hide it, it has plain old function and recursion as primitives. What makes it declarative is the lack of side effects and laziness.

What I'm trying to explain is that using the term "declarative" is confusing to a lot of developers who who not think of functional programming as declarative, but rather think of something like JSON.

Re: We want to make Nix better

#196

Post by dvdkon »

tikhonj wrote: post #85
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…

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…

I agree, even with FP and (some) Haskell experience, customising Nix and debugging what's going on is made hard by Nixpkgs being a complex codebase more than anything. However, it is different than the usual large web app. The problem of packaging software is fundamentally easy to break down into tiny pieces, the package definitions themselves. Arch's PKGBUILDs were very easy to understand for me as a novice, much better than RPM SPECs or whatever Debian has, so I think it's not impossible for Nix-equivalent packages to be similarly simple.

The biggest barrier, as I see it, is not actually Nix or Nixpkgs code, but the way NixOS differs from every other Linux distro. Most of my delving into Nixpkgs has been motivated by getting something working that would be trivial in a traditional distro. I agree the Nix language is a red herring, what's really needed is to make work other than "adding a package to Nixpkgs" easier. Actually usable introspection tools that the GP mentioned would be great.

Re: We want to make Nix better

#197

Post by grumbel »

ghoward wrote: post #195
grumbel wrote: post #182

Earlier quoted context omitted.

This shouldn't really come as a surprise, any reasonably powerful language will end up Turing complete sooner or later, it's pretty difficult to avoid. Nix specifically doesn't even hide it, it has plain old function and recursion as primitives. What makes it declarative is the lack of side effects and laziness.

What I'm trying to explain is that using the term "declarative" is confusing to a lot of developers who who not think of functional programming as declarative, but rather think of something like JSON.

I don't see it as confusing, it's a pretty accurate description. The Nix language is for most part a JSON-look-alike with a couple of additional features. You don't really program in it, you declare/return a data structure. The only programming you do in Nix is to make it a little easier to build that data structure. It's kind of like the old days when people would parse JSON with eval(), which would also grand you features that plain JSON wouldn't have.

Even NixOS itself doesn't do all that much actual programming in Nix, most of the code that does stuff is written in C++. The Nix language itself doesn't let you escape out of its sandbox.

Re: We want to make Nix better

#198

Post by Sugimot0 »

anderspitman wrote: post #87

For the first time in about 8 years an Arch update rendered my OS unbootable last week. I'd had graphics issues once or twice but this time it just hung in systemd somewhere. Still don't know what happened. Rolled all packages back about a month and that worked, but I'll need to update eventually. I'm considering Nix but don't like the custom language. I wish Guix were. more popular and less extreme on the freedom si…

Just a heads up, the issue was likely grub, grub had a breaking change for certain EFI devices. You can check arch news etc for more info. I had to chroot and fix my laptop the other day cause it was stuck boot looping after I upgraded.

Re: We want to make Nix better

#199

Post by senorsmile »

mamcx wrote: post #84
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…

My main gripe is documentation. Look at this: https://nixos.wiki/wiki/PostgreSQL Now, the real "workflow" with nix is look at other setups, or just look at the code: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/s... And look at the code is the only reliable way to see what exactly is supported. My second gripe is the fact is hard to see what nix do. Today I hit this trouble: https://www.reddit.com/r/Nix…

> What I wish now is something like:

> nix change nothing (if my changes somehow don't do anything, like in my issue)

I miss this feedback greatly having used Ansible since 2013 and only this year diving into a single NixOS installation as my intro.

Re: We want to make Nix better

#200

Post by [deleted] »

a1369209993 wrote: post #154
tikhonj wrote: post #85

Earlier quoted context omitted.

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…

> People rarely jump I'd just like to take a moment to reiterate that object-oriented programming is a mistake produced by cargo-culting half a dozen different styles used by competent programmers (including the devolpers of smalltalk and its relatives, from which OOP appropiated its name), and that Java is completely unusable by anyone with a sense of self-respect and a awareness that programming languages can be be…

[deleted]
Post reply on HN