Live data from Hacker News

How Nix and NixOS get so close to perfect

christine.website

161–170 of 183 posts

Re: How Nix and NixOS get so close to perfect

#161

Earlier quoted context omitted.

Say it with me: right tool for the right job. Not every language should try to solve every problem. And not every problem is nicely solvable in every language. By your definitions any language other than what, C and js is "unpopular" and "Rejected by the industry" ?

> Say it with me: right tool for the right job. Not every language should try to solve every problem. And not every problem is nicely solvable in every language. By your definitions any language other than what, C and js is "unpopular" and "Rejected by the industry" ? I literally claimed otherwise, elsethread > It's a reflection of what the programmers want. Apparently they wanted syntax with braces and semicolons. J…

I have no idea why you think you speak for "the industry", you maybe live in a bubble but fortran, cobol and haskell are alive and well...remember, the right tool for the job.

Re: How Nix and NixOS get so close to perfect

#162
post #116

Earlier quoted context omitted.

>Programmers have been looking at Haskell for 25 years and rejecting it. I really don't know why you think that true: https://wiki.haskell.org/Haskell_in_industry And i really don't know why you speak for "programmers", just speak for yourself...maybe?

>> Programmers have been looking at Haskell for 25 years and rejecting it. > I really don't know why you think that true: Because it doesn't show up any any metric as having significant usage. A list of 100 companies using it doesn't make the hundreds of millions of other companies not using it go away.

Your argumentation is just completely wrong, you think that "significant usage" is some kind of "quality". You try to argue that a hammer and a screwdriver are of significant usage, when i fact the best tool for the job is a scalpel.

FWI HN was not written in JavaScript or PHP but you can lookup that for yourself.

Re: How Nix and NixOS get so close to perfect

#163

Earlier quoted context omitted.

> Using Haskell as a base for the syntax I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: - Kind of like Lisp (parens everywhere, painful with pervasive currying); - Kind of like ML (var and fun everywhere); - Kind of like Haskell. Nix is chooses the last of those, and it does not have most of Haskell’s funkiness: no “…

> I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: How so? Where's the Java/Python-like languages in this consideration, why wouldn't those work? Or something more like Ansible? I'm pretty sure that you can express the same concepts for the most part in something imperative as well.

The Nix language's main concern is handling large scale configuration. General purpose programming and scripting is completely out of scope.

The Nixpkgs repository has over 80,000 packages [1] contained in a single key-value store. The design of the Nix language not only makes this sustainable, but even compelling. For one thing, Nix package descriptions are composable and easy to manipulate programmatically. It's common practice to create new packages on the fly out of existing package definitions, and it's what the Nix language is particularly good at. Things like this add a lot of complex inter-dependencies within the Nixpkgs code base, and it still manages to be comprehensible.

The same approach isn't practical with general purpose imperative programming languages. A quick glance at Nixpkgs repository reveals that it contains over 2.4 million lines of Nix code. Imagine that much Java/Python code manipulating a single global mutable data structure. It can only result in a nightmare.

Additionally, the notion that the Nix is Haskell and is therefore incomprehensible is an often repeated meme without any backing details and needs to stop. If any language is similar to Nix, it's Jsonnet. But I haven't seen a single person criticizing Jsonnet [2] for being Haskell. If you can understand JSON and have no problem writing functions for any common language, then there really should be no problem learning the Nix language.

[1]: https://search.nixos.org/packages [2]: https://jsonnet.org

Re: How Nix and NixOS get so close to perfect

#164
post #146

Earlier quoted context omitted.

So you found a concept that didn’t come naturally to you. If you are as successful at this field as you want us to believe, you would probably have learned by now that all technologies click differently for different people depending on the context they bring in when learning it. I can’t imagine taking myself so seriously that I would write a comment like this. This is an opportunity for self reflection more than a l…

This sort of attitude is what keeps Nix from reaching a wider audience.

[deleted]

Re: How Nix and NixOS get so close to perfect

#165
post #53

Earlier quoted context omitted.

Think about it like this: with Ansible you start from some unknown state of the system and then iteratively do actions to hopefully get what you want. With Nix you know what the base state of the system is, and the configuration language lets you describe your desired end state. Then the computer figures out what to do in the middle. The fundamental design of Ansible is that you do imperative steps to reach an end st…

> The fundamental design of Ansible is that you do imperative steps to reach an end state. No, the fundamental design of configuration management systems (Ansible, Puppet, Chef, Salt, CFEngine) is that they are declarative. You say "this software should be installed, this user should exist, these files should have these contents and permissions, etc" and they figure out the right steps to take on your OS to move from…

I deal with Chef at work, and I wish that was even remotely true. It's not a declarative system at all because it does not have the properties of being one. Namely the part about being able to specify the end state.

Chef doesn't allow you to specify the end state. Instead it allows you to specify a list of actions to be taken during deployment. The end result is affected by bunch of external inputs sent from the Chef server and every single bit of state the target server is able to observe. It is therefore impossible to reliably determine the end state of the target server before deployment. Our team has been burnt by this more than once.

Other similar systems are more or less the same. They have every hallmarks of being an imperative system.

Re: How Nix and NixOS get so close to perfect

#166

Earlier quoted context omitted.

> Because industry makes good decisions? That's irrelevant - if you want uptake, you need to support what user's want. It's been clear for at least a decade now that programmers don't want Haskell syntax. Whether it's a good syntax or not is irrelevant.

> That's irrelevant - if you want uptake Haskell's slogan is "avoid success at all costs". Haskell isn't aiming for mass adoption. It wants to be a language for researching functional programming, it just so happens it's a useful language, and people write real software with it too. From https://haskell.foundation/whitepaper/ > Haskell's slogan of "avoid success at all costs" was a clever and cheeky way of saying tha…

Do note that it should be read as "avoid success at all costs" though, which changes the meaning quite a bit.

Re: How Nix and NixOS get so close to perfect

#167
post #146

Earlier quoted context omitted.

So you found a concept that didn’t come naturally to you. If you are as successful at this field as you want us to believe, you would probably have learned by now that all technologies click differently for different people depending on the context they bring in when learning it. I can’t imagine taking myself so seriously that I would write a comment like this. This is an opportunity for self reflection more than a l…

This sort of attitude is what keeps Nix from reaching a wider audience.

What’s your title and your employer’s market cap? I need to know how seriously I should consider your opinion..

Yes, Nix is incredibly complicated and needs to improve to see more adoption.

I was just commenting on the weird flex of the OP.

Re: How Nix and NixOS get so close to perfect

#168
post #144

Earlier quoted context omitted.

Whether it's worth it or not depends on your skill as a programmer, your IQ, and/or the amount of time your willing to spend on learning it. Smarter people can pick it up quicker while stupider people will need to spend more time. For stupider people, it's not worth the investment. On average I would say it takes maybe a couple months of wrestling with it to fully pick it up and you'll still encounter problems on occ…

While Nix / NixOS is very clever, I think this video enumerates enough pain-points why you'd not want to dabble with it for your 1-2 hosts at home. Only the security point is enough to convince me it sadly do not belong to our production or office-LAN. For most of us, it's a benefit/cost analysis. I've no doubt I can figure it out, but last time I tried, a package came with defaults that differed from just running a…

It's used for deployment of an entire operating system for edge devices at the company I work for. Especially for C++ it fixes alot of dependency nightmares.

However it takes about 6 months for a new hire to ramp up to nixos. The only reason why our company uses nixos is because someone really smart was part of the founding team.

Docker is a good alternative... but honestly if you think about it, instead of using containers for OS's an OS itself should be designed to deal with this problem. It works in the same way type script works as type script is an effective an elegant hack to get around the warts of javascript.

Re: How Nix and NixOS get so close to perfect

#169

Hmm I don't know Nix very well. But the features described in the blog post. Aren't they very similar to the features of docker ? And docker doesn't hat all of these "paper cuts".

Docker has it's own "paper cuts." Such as only being able to cache sequential build steps, not being very reproducible, etc.

Re: How Nix and NixOS get so close to perfect

#170
post #76

>> "bad documentation" One thing I still can't figure out is if nix (or flakes) allows you to pin packages to a specific version. Does anyone now if that's possible and how? E.g. (pseudo code below) services.nginx.version="1.21.4" services.nginx.enable=true

Another option: I often just manually vendor the nix files for the version of the package and/or service I want.

You can supply a particular package version to most services e.g. `services.nginx.package`.

Or if you need to vendor a service, you can copy it into your local repo and use `disabledModules` to prevent the loading of the original.

I haven't used them yet, but I think flakes will make this a lot easier, if my understanding of them is correct.

Post reply on HN