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

Nix – Death by a Thousand Cuts

dgt.is

Post reply on HN
Print view View original

221–230 of 336 posts

Re: Nix – Death by a Thousand Cuts

#221

Post by rcxdude »

rob_c wrote: post #72
azeirah wrote: post #69

Earlier quoted context omitted.

The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be cleaned up, and things _are_ getting better. The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.

It's basically, I refuse to learn how to containerize. Just learn, use, promote best practices and stop forking the ecosystem _even_ further... There, I got that off my chest.

containers with build scripts are a bandaid over broken systems, it's better practice then having zero executable documentation on how to stand up a system, but it's also far from the best that could exist.

Re: Nix – Death by a Thousand Cuts

#222

Post by hamandcheese »

SuperSandro2000 wrote: post #167
sshine wrote: post #64

Earlier quoted context omitted.

> I figure that the developers know what they're doing and haven't made them the blessed path yet for a reason. My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes. They’re just an interface for a decentralised module system. You can use them, they’re feature-complete, and they don’t align with nixpkgs: it doesn’t make sense for individua…

Flakes bring you one interface to share common dependencies which is kot possible without an interface.

That interface could have been built in vanilla nix, though.

Instead, a bunch of very useful features are bundled with flakes, like pure eval, eval caching, and git-awareness. But flakes still have some showstopping usability issues preventing users from benefiting from these great features. Issues like that it copies your repo root to the nix store on every evaluation, which scales terribly to bigger repos. Not to mention other issues like the extremely limited ability to override a flakes inputs - you can't pass a configured instance of nixpkgs for example.

Generally speaking, the more advanced the use case, the more likely it is that flakes won't work well. Which probably helps explain why flakes are still unstable after so many years.

Re: Nix – Death by a Thousand Cuts

#223

Post by tomn »

nothrabannosir wrote: post #197
tomn wrote: post #174

Earlier quoted context omitted.

> I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the similar lazy nature of the language. My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by…

I don’t understand—the language itself is completely contained and separate from the derivation. Evaluation could be done in any language and the derivation will remain the output. You can absolutely have a better language generate derivations, surely? Hell, you could use Python typescript or go if you wanted to. They’d even be completely compatible with the unholy mess of cursed bash that is stdenv. What you can’t p…

> You can absolutely have a better language generate derivations, surely?

Yes, hence guix. The issue is that it doesn't fit well into a pure functional language like haskell if you want to allow import-from-derivation or basic functions like "readFile", without putting everything in IO (complicating the DSL).

https://nix.dev/manual/nix/2.25/language/import-from-derivat...

What you can’t port over to another language as neatly are the modules. Good riddance, id say. Undebuggable spaghetti from hell.

Not that it matters, but why not? Modules are written in the pure-functional bit of nix, so could be expressed in practically any language.

>> from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).

> Unfortunately I have wasted enough of my life to call myself “on the inside” and IMHO the language itself is close to the number one threat to wider adoption of nix.

I guess different people have different experiences. This was mainly based on my personal experience, but if you look through the help section on discourse, the questions are not about the language (at the time of writing i didn’t find even one in the first few pages):

https://discourse.nixos.org/c/learn/9

There also just doesn't seen to be a big push in the nix community to replace the language. Nickel exists, but i don't see the push for that from the nix side.

Re: Nix – Death by a Thousand Cuts

#224

Post by gf000 »

dingi wrote: post #190
whazor wrote: post #130

Earlier quoted context omitted.

Nix currently has the most packages of any distribution, see https://repology.org/ The model of having packages on Github with pull requests scales very well. Therefore, you could argue that people are getting things done with Nix.

> Nix currently has the most packages of any distribution, see https://repology.org/ This is a meaningless point. Different distros split packages differently.

Nix's ecosystem really has exploded over the last couple of years. Even very obscure packages can be found, that are definitely AUR/PPA-territory in other distros.

At least, that's my personal experience.

Re: Nix – Death by a Thousand Cuts

#225

Post by oDot »

pkkm wrote: post #95
Baeocystin wrote: post #65

The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".

Your veiled implication that Nix and NixOS aren't about "getting things done" is, I think, more than a little unfair. I'm using multiple programming languages at work. Each one of them has its own dependency manager that does basically the same job as the other ones. In Python it's Poetry, in Ruby it's Bundler, in JavaScript it's npm/yarn, in PHP it's Composer, etc. A lot of projects require extra setup steps outside…

I use Nix and agree with most of what you said, except the main value proposition of docker-on-dev-machine is not convenience, but approximation of production

Re: Nix – Death by a Thousand Cuts

#226

Post by neobrain »

ofrzeta wrote: post #193
edude03 wrote: post #160

Earlier quoted context omitted.

I'm not talking about a bit perfect reproduction though, just being able to understand dependencies. Take for example a simple Dockerfile like ``` FROM python:latest ADD . RUN pip install foo ``` If I run this today, and I run this a year from now, I'm going to different versions of `python` and `foo` and there is no way (with just the Dockerfile) to know which version of `foo` and `python` were intended. Nix on the…

Well, what about "FROM python:3.18" and using requirements.txt or something like that? I mean, running an arbitrary Python version will get you in trouble anyway.

There's no mechanism to enforce this is done consistently. With nix, there is.

The degree to which this guarantee is useful or necessary depends on your use case.

Re: Nix – Death by a Thousand Cuts

#227

Post by choobacker »

zie wrote: post #175
SuperSandro2000 wrote: post #172

Earlier quoted context omitted.

LTS is harming the industry and holding everything back! IMO it is the wrong direction.

Why do you think that? That seems like a pretty extreme viewpoint to me. Stability is a great thing for busy professionals that want stuff to just work. How many apps have you upgraded that have crashed and burned from the update? Me, a lot. both commercial and OSS. With OSS at least you get all the pieces so you can figure out how to put it back together again. With Commercial, you rollback, file a bug report and ho…

To mitigate breakages we should be aiming for better test coverage, at various build levels: class, package, program, system.

Our industry's story for system-level testing, for Linux distributions, is poor. NixOS tests are decent, but need more coverage, and something similar needs to be available to upstream so issues are caught during development.

Meanwhile, LTS releases have downsides:

* Alienating you from upstream: why contribute upstream if you'll only benefit from them in 2 years.

* Having to support stable versions makes refactoring harder. Developers don't want stable to be too different, lest backporting becomes too tricky.

* Maintenance costs is sunk, compared to if we can make rolling release reliable (see above re tests, and easy rollbacks).

https://abseil.io/about/philosophy#we-recommend-that-you-cho... is the same idea but from Google C++ team.

Re: Nix – Death by a Thousand Cuts

#228

Post by mkhalil »

My journey with NixOS is as follows: 1) great and useful for development work. (I use NixOS inside WSL) 2) but for your general Desktop environment, I'd say it's only great and useful if you find "tooling" fun/as a hobby (i.e. the type of person who keeps their dot-files updated in a git-repo [although, you won't need dot-files anymore :)]

I would say the biggest negative is that it seems the development of it is disjointed, as there are almost too many ways to do the same thing; some things are being deprecated before the documentation even keeps up with development.

--- personal notes: --- Also, some things are finicky and require some understanding to get to work (e.g. getting VSCode (on Windows) working with language analyzers and code sitting inside a WSL NixOS distro)

- I love Flakes but don't really love home-manager; I can understand home-manager being useful if your using Nix and not NixOS. - My NixOS rules pretty simple: 1) A per-project flake.nix + direnv file (or an env playground) 2) Configuring "etc/nixos/configuration.nix" for global tools like "wget, git, etc." (don't get me started with programs..enabled, see above for "too many ways to do the same thing")

Re: Nix – Death by a Thousand Cuts

#229

Post by tempfile »

SuperSandro2000 wrote: post #154
Zambyte wrote: post #63

Earlier quoted context omitted.

I switched away from Nix OS and eventually landed on GNU Guix, which I have stayed on for about 4 years now. One of the main reasons I switched away from Nix was because of the language, and how underdocumented it all felt. GNU Guix was a breath of fresh air, using a language with decades of academic backing outside of the context of Guix (SICP was awesome for getting into it) and the whole system is very well docume…

Guix has stripped away the biggest plus from NixOS: the module system and replaced it with a half assed system

Can you say why you think nix modules are the "biggest plus" from NixOS? They don't even make the top 5 for me.

Re: Nix – Death by a Thousand Cuts

#230

Post by 331c8c71 »

jmholla wrote: post #116
0x457 wrote: post #108

Earlier quoted context omitted.

> My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes. I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them. Flakes aren't default due to political reasons.

> I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them. Can you share some examples of such problems?

With flakes I can get other people to run exactly the stuff I packaged with one command e.g. `nix run github:...` which can also be a reference to specific commit BTW.

At this point I don't even quite remember what would be the sane alternative without flakes but I am happy to discuss...

Post reply on HN