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

The Curse of NixOS

blog.wesleyac.com

Post reply on HN
Print view View original

131–140 of 361 posts

Re: The Curse of NixOS

#131

Post by jeremyjh »

nicoburns wrote: post #119
qudat wrote: post #118

I didn't go all-in with nixos -- and I'm thankful I didn't. I simply tried using it for local development. I thought that I could replace the various language version managers with nix. I spent weeks working with nix to understand the language, how to use it, and reading as much documentation/blogs as possible. One really frustrating thing about nix I noticed early on is the lack of support for older language version…

I've recently discovered `asdf` ( https://github.com/asdf-vm/asdf ). It's not as technically clever as nix, but it does allow you to manage version of most language toolchains with one tool.

This is a great tool, I've used it for years. Its not really meant for production systems, but to manage multiple versions of Python, Node, Elixir, Erlang, Ruby etc it works great.

Re: The Curse of NixOS

#132

Post by JamesSwift »

qudat wrote: post #125
JamesSwift wrote: post #49

Earlier quoted context omitted.

I moved to Docker for ruby/rails dev long ago and never looked back. Trying to do it locally, especially if there are others involved, is a path to pain and frustration as "works on my machine" creeps into a `bundle install` every few months.

After having spent weeks learning nix, I'm convinced that docker is simply a better tool for most use-cases of nix.

Coming from docker before nix, I think nix is a better version of docker for some use-cases. If the ecosystem is supported then I much prefer nix for speed (both runtime and development speed)

Re: The Curse of NixOS

#133

Post by CameronNemo »

parasense wrote: post #127

I used to think the ideas of NixOS were great, but then I learned about `ostree`, and in my opinion things like Project Atomic (in Fedora), are probably more pragmatic or straightforward idiomatic implementation of those ideas. In essence the software packages resemble how git works behind the curtain. Git has a bunch of objects with cryptic names resembling hashsum's, and those are the files in your git working tree…

You can checkout a branch of the root filesystem on bootup, etc... and it's great for A/B testing because if there are any problems one simply boot into the previously known-good branch, etc.

You can also do this with NixOS, or even ZFSBootMenu.

Re: The Curse of NixOS

#134

Post by deusum »

DrBazza wrote: post #32

In the footnote: > borgcfg ... Truly one of the worst languages I have ever seen. I'll see your borgcfg and raise you a reverse-Polish notation stack based one, written in a couple of hours and supporting a repo trading system for an investment bank for years.

And this whole time I thought the finance world was held up on an Excel spreadsheet.

Re: The Curse of NixOS

#135

Post by dmitriid »

ghostwriter wrote: post #50
rgoulter wrote: post #35

Earlier quoted context omitted.

Nix is wonderful, but absolutely is under-documented. (In part due to a small community, etc.). A couple of examples I've run into: https://github.com/NixOS/nix/issues/2259 showed people trying to make use of the "hello world" package which was given in the NixPkgs manual, but couldn't quite figure out how to get it to build. e.g. if you want a package that's a simple script, "writeScriptBin" seems like what you'd wa…

> you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri ... Is it too much to ask from developers in 2022? At source, the function is well documented and is provided with an example [1]. The only missing part is a rendered HTML with the same information. [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

> Is it too much to ask from developers in 2022?

In 2022 it's not too much to ask from the developers of the tools to provide:

- consistent and up-to-date documentation (that's built and updated together with the source code)

- consistent, readable and understandable error messages

Re: The Curse of NixOS

#136

Post by Filligree »

rgoulter wrote: post #96
mplanchard wrote: post #53

Earlier quoted context omitted.

The best way I’ve found around this is to always keep a local clone of nixpkgs so that I can grep for where functions are defined and hope like hell that there are some comments in the vicinity. Definitely not ideal.

If you're using Nix on your system, you can also find nixpkgs symlinked under ~/.nix-defexpr/channels/nixpkgs/pkgs/ or so.

And if you have flakes and nix-command enabled, you can run `nix edit nixpkgs#lib.sort` to get the definition of the sort function.

(This will just tell you it's imported from lists. `nix edit nixpkgs#lib.lists.sort` will get you the actual definition.)

Re: The Curse of NixOS

#137

Post by zeec123 »

roblabla wrote: post #126
qudat wrote: post #118

I didn't go all-in with nixos -- and I'm thankful I didn't. I simply tried using it for local development. I thought that I could replace the various language version managers with nix. I spent weeks working with nix to understand the language, how to use it, and reading as much documentation/blogs as possible. One really frustrating thing about nix I noticed early on is the lack of support for older language version…

I am all-in on nixos. I've also experienced those problems, but I for one am glad that those don't work. Let me explain. My use-case for Nix is to make my build system so reproducible that, if I get back to the project in five years, it should still compile, and if I give it to someone else, they should be able to make it work without any issue. Like the install steps for them should be as simple as "Install nix, the…

I fully agree, but which there would be an escape hatch when needed. It is especially frustrating for python developers.

Re: The Curse of NixOS

#138

Post by zeec123 »

snicker7 wrote: post #103

Guix configuration is in Lisp, a well-established language (60 years and still strong). Moreover, Guix package code is written in a clear, declarative style. Nix package definitions, on the other hand, typically embed shell scripts in them.

Yes, but systemd is missing and most drivers because they are not gnu.

Re: The Curse of NixOS

#139

Post by zeec123 »

yewenjie wrote: post #65
altgans wrote: post #56

I am a NixOS user, but am interested in Guix. Based on a cursory look I have some questions: - How big is Guix on GNU? Does it throw wrenches in your way if you do anything "unfree"? How easy is it to install the nvidia-drivers? - How is the package ecosystem? 20.000 official packages seems a little low? Are there community packages? How easy it is to create your own packages? Why is the Neovim package only at versio…

Yes, the low number of readily available packages is the primary reason I switched from Guix to Nix.

And properitary drivers.

Re: The Curse of NixOS

#140

Post by IshKebab »

gorjusborg wrote: post #100
count wrote: post #13

Earlier quoted context omitted.

We already had JSON plus functions. We called it 'JavaScript' :)

Ha, nice! Seriously though, javascript is not a great language if you are looking for robust determinism. I can understand their decision to go elsewhere, given the domain and design.

People have tried: https://github.com/jkcfg/jk

But yeah I agree. The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts?

Google had the same problem for Bazel, and their solution (Starlark) is way easier to understand.

Post reply on HN