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

231–240 of 336 posts

Re: Nix – Death by a Thousand Cuts

#231

Post by gf000 »

Zambyte wrote: post #63
_huayra_ wrote: post #55

I've been on the fence about Nix. I've wanted to love it (and do love the concept), but between the Waiting-for-Godot situation for flakes, the weird language, and the occasional political infighting I've seen pop up about the community, I still haven't switched. 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 simil…

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…

4 years can be a very long time in a project, especially when the "network effect" hit around that time, where the active user count (and contributions) grown significantly.

Also, the language is quite simple, it's just foreign and you felt more at home with Scheme, so you might not have given Nix as much of a chance. This is the classic "simple vs easy" from the Hickey talk.

Documentation is no perfect, but has become quite a bit better over the years, and many of the problems that still linger are simply architectural ones of the nixpkgs repo, irrespective of language and wouldn't be solved in any other language/DSL in itself.

Re: Nix – Death by a Thousand Cuts

#232

Post by Joker_vD »

ofrzeta wrote: post #195
stouset wrote: post #140

Earlier quoted context omitted.

I tend to agree. I also think both sides need to learn to better appreciate the other. Without people getting shit done with the tools we’ve built, there would be no demand for better tools and no need to write them. Without better tools, the things we can get done are limited. Better tooling is an exponent to our productivity. The things we can accomplish today would have been nearly unimaginable nearly thirty years…

> The things we can accomplish today would have been nearly unimaginable nearly thirty years ago. Like what? Witing an entire operating like Linux or Windows NT from scratch?

Well, no, that's still a Herculean effort. But look at all of those slick TODO apps we are now building non-stop!

Re: Nix – Death by a Thousand Cuts

#233

Post by hamandcheese »

mkhalil wrote: post #228

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 dis…

> don't get me started with programs..enabled, see above for "too many ways to do the same thing"

programs..enabled implies that there is some system configuration needed in order for the program to function (or in home manager, the analog would be user configuration in your home directory).

Whereas environment.systemPackages simply puts bins on your path.

Re: Nix – Death by a Thousand Cuts

#234

Post by viraptor »

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.

Depends on the repository used, actual version revision of Python, compiled features, the way the requirements file is written, the way the current version of pip resolves them, the base is that Python image and a lot of other things. Doing that gives you maybe 30% of the way towards something reproducible and consistent.

Re: Nix – Death by a Thousand Cuts

#235

Post by kstenerud »

tomn wrote: post #223
nothrabannosir wrote: post #197

Earlier quoted context omitted.

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…

> but if you look through the help section on discourse, the questions are not about the language

Mostly because people don't know how to ask questions about the language. That was my experience.

Over the past decade I've made a few forays into Nix and NixOS (I still need to revert one of my servers back to Debian from NixOS). Inevitably I find the language obtuse, and the help online is always in the form of code fragments whose purpose kinda sorta looks alright maybe, but doesn't ever seem to fit into the setup I've built. So then I'm faced with completely rearranging the structure to match the helpful code, or try to massage the helpful code into my structure (which may or may not be a monstrosity, nor could I explain what every one of the magical incantations are for). Rinse and repeat with the next problem.

So it becomes essentially impossible to ask questions about it because I don't actually know where one thing ends and another begins.

After awhile, I start asking myself "Why was this a worthwhile venture again?"

I've heard good things about guix though. Might give that a try next. I'm done with Nix - burned one time too many.

Re: Nix – Death by a Thousand Cuts

#236

Post by [deleted] »

turboponyy wrote: post #204
rob_c wrote: post #72

Earlier quoted context omitted.

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.

Containerizing an application is far easier than packaging an application for Nix - I think most avid Nix users would agree with that. The reason why Nix users "refuse" to containerize is that Nix packages and their associated ecosystem come with a host of benefits that their containerized counterparts do not.

[deleted]

Re: Nix – Death by a Thousand Cuts

#237

Post by azeirah »

oDot wrote: post #225
pkkm wrote: post #95

Earlier quoted context omitted.

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

Nix works extremely well _with_ Docker! That's what makes it so interesting.

https://www.youtube.com/watch?v=0uixRE8xlbY

Re: Nix – Death by a Thousand Cuts

#238

Post by cpuguy83 »

lmm wrote: post #166
XorNot wrote: post #131

Earlier quoted context omitted.

You can just store the actual container though. Which will reproduce the environment exactly, it's just not a guidebook on how it was built. The value of most reproducibility at the Dockerfile is that we're actually agnostic to getting a byte-exact reproduction: what we want is the ability to record what was important and effect upgrades.

> Which will reproduce the environment exactly, it's just not a guidebook on how it was built. By that logic every binary artifact is a "reproducible build". The point of reproducibility isn't just to be able to reproduce the exact same artifact, it's to be able to make changes that have predictable effects. > The value of most reproducibility at the Dockerfile is that we're actually agnostic to getting a byte-exact…

None of this has anything to do with Dockerfile but the tools used within.

Nix provides the tooling to do reproducible builds. Meanwhile docker is a wrapper around the tools you choose.

Also just to note, docker does allow you disable network access during builds. Beyond Dockerfile, which is a high level DSL, the underlying tech can do this per build step (in buildkit LLB).

Re: Nix – Death by a Thousand Cuts

#239

Post by tomn »

kstenerud wrote: post #235
tomn wrote: post #223

Earlier quoted context omitted.

> 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…

> but if you look through the help section on discourse, the questions are not about the language Mostly because people don't know how to ask questions about the language. That was my experience. Over the past decade I've made a few forays into Nix and NixOS (I still need to revert one of my servers back to Debian from NixOS). Inevitably I find the language obtuse, and the help online is always in the form of code fr…

> the help online is always in the form of code fragments whose purpose kinda sorta looks alright maybe, but doesn't ever seem to fit into the setup I've built. So then I'm faced with completely rearranging the structure to match the helpful code, or try to massage the helpful code into my structure (which may or may not be a monstrosity, nor could I explain what every one of the magical incantations are for)

None of these are language problems, they are problems with the way nixpkgs is structured and the ways nix is used (or your understanding of those).

Perhaps being purely functional causes some of this complexity/unfamiliarity, but in that case replacing it with another pure functional language (the original point i was replying to) is not going to help. Maybe replacing it with scheme (functional/imperative) does, I don't know.

Re: Nix – Death by a Thousand Cuts

#240

Post by megaloblasto »

I love nix. I use nixos with flakes, syncthing and direnv. My directories are development environments. My projects are reproducible and portable to different architectures. I don't use the language specific package managers, I have one that can bind them all. Nothing is lost in a tangled mess of imperative configuration choices. My file system is clean and organized. Everything is how I told it to be. I am happy.
Post reply on HN