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

151–160 of 204 posts

Re: We want to make Nix better

#151

Post by ghoward »

theCodeStig wrote: post #123
ghoward wrote: post #76

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…

Ok then, would you consider markup languages declarative, XML... XSLT?

Yes. They are declarative.

Re: We want to make Nix better

#152

Post by ghoward »

theCodeStig wrote: post #125
ghoward wrote: post #112

Earlier quoted context omitted.

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.

Laziness, and purely functional go a long way toward declarative.

Declarative has a few definitions with respect to computer languages, and the Nix community seems to be using one and ignoring others.

When I think of declarative, I think of a language that has less power than a Turing-complete language. Think Make without bash or any shell. Or HTML without CSS.

In other words, the Nix community seems to use "declarative" as meaning "without side effects" where some programmers, like myself, hear "declarative" and think of something like HTML without CSS or JSON.

Re: We want to make Nix better

#153

Post by nextaccountic »

mixedCase wrote: post #51

Hot take as a NixOS user that uses Nix for work: "all" we need is a much better, sound, statically typed language to build better abstractions with. The only hard requirements I can think of are algebraic data types with exhaustive pattern matching to go with, row polymorphism, purity and good inline documentation support. I don't know if a good enough hostable language exists or if it should be a new version of Nixl…

Can Dhall be that language?

Re: We want to make Nix better

#154

Post by a1369209993 »

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…

> 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 better than least-common-denominator noe-COBOLs. I'm not familiar with the specific codebase you're refering, but it would probably be at least less massive and less awful if it had been written in a more decent language, like Haskell or C.

Re: We want to make Nix better

#155

Post by ghoward »

throwamon wrote: post #121
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.

Although it's debatable, it's very common for functional languages to be categorized as declarative.

Perhaps, but that categorization is going to confuse a lot of developers. It sure confused me until I said something wrong, and all of you Nix proponents descended on me.

This confusion is not good for Nix.

Re: We want to make Nix better

#156

Post by xyzzy_plugh »

Bolkan wrote: post #140
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…

What nix needs more than anything is a centralized repository containing recipes for running all the different kinds of programs, as nic files. ie a dockerhub alternative.

nixpkgs?

Re: We want to make Nix better

#157

Post by colordrops »

Bolkan wrote: post #142
mamcx wrote: post #84

Earlier quoted context omitted.

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…

Yeah, dealing with user directory is a pain, and it is a pain because you can't make it completely functional (what about passwords). And it is the only place I found where nix doesn't work as you would expect it to in my 3 years of nixos use.

You can use agenix for secrets management. You can store all secrets encrypted with your SSH key in public config. The only non functional part is installing your SSH key, which is probably not a bad thing.

Re: We want to make Nix better

#158

Post by colordrops »

dd_ wrote: post #146

As someone who has been using NixOS for a couple of years now, I really want to say how appreciative I am of everybody for making noticeable improvements to the system on a somewhat regular basis. The nix command keeps on adding great new features like flake templates and bundling as well as just being more user friendly (error messages, actionable hints, etc.) Additionally, tools like nix-ld [1] make nix more usable…

Yes, I could imagine a very locked down opinionated distro built on top of Nix that completely abstracts away all of it and makes it work somewhat like Ubuntu with some prepared nix templates/metaprogramming to automatically generate config. Over time more of the Nix functionality could be exposed through UI or more friendly cli tools as best practices and nix itself evolve, allowing the distro to remain friendly to non-technical users while opening up it's true powers to them.

It wouldn't be able to handle arbitrary manual changes to config at the beginning, so either there would always be a protected generated config region of the whole config and the distro would remain relatively standardized, or an alternative evolution would be a low-code user friendly UI that could map to any possible nix config.

Re: We want to make Nix better

#159

Post by zuzuleinen »

rgoulter wrote: post #141
zuzuleinen wrote: post #60

Earlier quoted context omitted.

I wrote a short guide[1] how bob uses Nix, but essentially we still use `nix-build` under the hood to build a list of packages you give under dependencies > Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. Are you referring here to packages which are not available in Nixpkgs? [1] https://bob.build/docs/usage/package…

The point is: a couple of the tough points in packaging something with Nix are "how to come up with the Nix expression", but also how to get the software you're packaging to build with the constraints Nix has (no fetching external dependencies, shared libraries explicitly declared in non-standard locations, etc.). A bespoke YAML format is arguably not simpler than just "here's the equivalent Nix expression". But, sur…

> But, providing a nice facade over the Nix language doesn't help with cases of where Nix can be difficult to work with.

This is true. If you reach the point where you need to write your own Nix expression you currently can become stuck.

But I think these are problems that are waiting to be solved. There are folks are already working on a new language tutorial at nix.dev for example and other tools that can abstract some of the problems we have now can be built. I believe we are still in an early stage when it come to reproducibility and we just have to keep working at it.

Re: We want to make Nix better

#160

Post by [deleted] »

rgoulter wrote: post #143
ParetoOptimal wrote: post #71

Earlier quoted context omitted.

> Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. The basic way to fix this with nix is: 1) download the thing with a fixed ouput derivation: a derivation who's source has the URL and checksum of the artifact 2) copy the artifact from the nix store where said build tool stores it

In nix expressions, sure; but bob uses YAML, and uses that to drive nix.

[deleted]
Post reply on HN