If a lot of people used NixOS, the world would be a better place to live - Tommy Wiseau
Nix: Taming Unix with Functional Programming
141–150 of 205 posts
Re: Nix: Taming Unix with Functional Programming
#142Earlier quoted context omitted.
I have tried Guix (as a package manager), and it seems much better documented. I also really like the fact that Guix uses a well-established, minimalistic, well-implemented, functional-preferred configuration language, which is Guile, the GNU implementation of Scheme, which is very much tailored to be extended with and embedded in other software, for example written in C. In part, my love comes from having had to use…
> minimalistic The Nix language is far more minimalistic than any Scheme. I have nothing against Scheme but let's be clear, Nix out-Schemes Scheme in this regard.
People complain about learning 'the language' when the thing they've really been trying to learn is actually:
- the language
- the stdlib (nixpkgs.lib)
- the NixOS module system
- several particular packaging ecosystems (stdenv, buildGoModule, buildPythonApplication, etc.)
- the hooks and stuff that get exposed as variables and functions in bash-based builders
It makes sense as a shorthand, and I'm sure it describes the feeling, that people say 'learning the Nix language was overwhelming at first', because using the language in the context of all of those other things (essentially libraries and applications written in Nix) is the context in which one generally tries to learn it. And that really can be a lot to take in at once.
But I think when someone says 'learning the Nix language was hard' or something similar, it does sometimes mislead others about the complexity of the Nix language itself. So there's this widespread misconception that Nix-the-language has a lot to it.
But like you say, the language itself is actually super minimal. (And really good for its intended purpose, imo.)
Re: Nix: Taming Unix with Functional Programming
#143Earlier quoted context omitted.
Nix attracts whiners - 90% people happy with it are happy using it and not bothering to waste energy arguing with bad attitudes online.
Well, it's easier to be contrarian online. Though I anticipate better discussion from "nix didn't suit me" than "nix works". Looking at Nix's community survey, there's been a big growth in the community over the last year or two. I think most who try nix like it, and see it as so obviously a good technology.
My pet peeve (which is present in this thread!) is when people link Nix discourse or github discussions and say "look how ridiculous it is to do XYZ in Nix."
The community discussions are one of the best parts of Nix. People are super helpful and work together to solve novel problems all the time!
In fact, those threads are people doing something about "nix didn't work for me."
Re: Nix: Taming Unix with Functional Programming
#144Earlier quoted context omitted.
> As an observer it looks like Python's package ecosystem in particular is a giant mess. Most people would say it is. The better question is how to avoid such a mess. My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. And yeah, that has also become a cultural issue with Python, as the Python2/3 breakage shows. So, could one sum it up in th…
> My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. Given that software developers never guess the correct design up front this means that you always have architecturally buggy software, and a bunch of complaining about why buggy-looking edge conditions are never fixed. There has to be some kind of release valve for software to evolve and…
> There has to be some kind of release valve for software to evolve and break backwards compatibility.
You kinda insinuate that breaking backwards compatibility is kinda necessary at times.
This is not the case. Projects like
* the Linux kernel, or
* the GNU C library, or
* the Numeric -> Numpy transition around Python 2.0, or
* Common Lisp (which is much older than Python) adopting Unicode
are good examples that this is not necessary. It is not true that you have to break backward compatibility.
There are domains where breaking backwards compatibility in libraries is not acceptable at all, like vendor libraries in industrial automation. You don't throw away a 15-year old printing machine or a chemical plant just because the vendor of the automation software is tired of supporting its old interfaces.
That might sound strong, but others have expressed it more strongly. Read this: https://linuxreviews.org/WE_DO_NOT_BREAK_USERSPACE
How it is done? It starts with well-designed interfaces. And when interfaces are changed, the old interfaces are kept and become special cases of the new ones. Numeric/Numpy is a good example.
Here is a talk, brilliant as always, by Rich Hickey which explains why and how:
https://www.youtube.com/watch?v=oyLBGkS5ICk
It is highly relevant to Nix and Guix.
Python3 could have gone the same way - keeping the interpreter compatible to Python2 code, making the semantics dependent on whether a source file has a *.py or a *.py3 extension, and so on. It would have been more work but the transition would have been nearly painless, and I guess much faster. Support for old stuff does not need to go on forever - for example, Linux does not support any more Intel 386 CPUs.
It boils down to whether keeping stuff backwards-compatible is a goal of the project leaders or not.
Re: Nix: Taming Unix with Functional Programming
#145Earlier quoted context omitted.
> My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. Given that software developers never guess the correct design up front this means that you always have architecturally buggy software, and a bunch of complaining about why buggy-looking edge conditions are never fixed. There has to be some kind of release valve for software to evolve and…
Yes they've invented that: It's called bumping the major version.
> Yes they've invented that: It's called bumping the major version.
Rich Hickey's Talk:
https://www.youtube.com/watch?v=oyLBGkS5ICk
explains why this is not a solution. It makes a difference, yes. But it is the difference between "the incompatible changes in my library are going to break your application" and "the incompatible changes in my library are going to break your application, and I am telling you this beforehand".
Re: Nix: Taming Unix with Functional Programming
#146Earlier quoted context omitted.
The parent comment is complaining about Python 2/3 breakage which was a major version.
Not exactly, they're saying that the Python 2/3 breakage debacle became a model for how packages are maintained in general.
> they're saying that the Python 2/3 breakage debacle became a model for how packages are maintained in general.
And isn't that true?
Re: Nix: Taming Unix with Functional Programming
#147Earlier quoted context omitted.
Not exactly, they're saying that the Python 2/3 breakage debacle became a model for how packages are maintained in general.
Well they should clarify because they cite the example of the 2/3 breakage which is a major version break, and they're not complaining about packages just violating SemVer so I don't think your interpretation makes sense. It also certainly wasn't what I was responding to, and responding with "hurr durr major versions" like I've never heard of them before is just mildly insulting (and kind of insulting to the parent c…
> they're saying that the Python 2/3 breakage debacle became a model for how packages are maintained in general.
As explained above, semver is not a solution. And it is often not really followed. For example, boost is breaking backwards compatibility some times, and this is causing problems, last not least because boost Python bindings are used in so many projects.
Re: Nix: Taming Unix with Functional Programming
#148Earlier quoted context omitted.
I use Nix on an array of devices (any combo of x86/aarch64 and Linux/Darwin machines you can imagine), and while I really do love the experience, you're right that ARM is a sticking point. It's been getting better over the past few months, but still not close to x86 packaging parity. On the other side of that coin, I tried switching back to Arch a few weeks ago after ~4 months of NixOS. Maybe it's the sunken-cost fal…
Is there a way to get it so that UI applications installed with Nix show up in Spotlight Search? I remember that being my big annoyance when I tried using Nix instead of Homebrew on MacOS.
Yeah, if you use a module system like Nix-Darwin or Home Manager: https://github.com/nix-community/home-manager/issues/1341#is...
(Hopefully comparable modules are on their way onto the defaults for each of those module systems)
Re: Nix: Taming Unix with Functional Programming
#149Earlier quoted context omitted.
I think nix probably needs a more beginner friendly documentation as well, by beginner friendly I mean Linux beginners. Beginners will not read through nix pills (assuming they can understand it) before trying nix, they will just give up. And there are a lot of Linux users who don't have much technical knowledge about how binaries are being linked, etc. I think the ecosystem is now mature enough for beginner users to…
Nix is a programming language and there is no visual editor for it yet.
Yes, but for simple usages it is somewhat similar to things like JSON, they don't have to learn a language to install some commonly used packages.
Re: Nix: Taming Unix with Functional Programming
#150Earlier quoted context omitted.
I much prefer Guix UI-wise but it has some downsides: — I’ve had more jank on Guix System as a desktop OS than on NixOS. Specifically some dbus-related stuff like notifications and appindicators (when running sway + waybar) has been very unreliable for me under Guix in ways that it hasn’t been on any other distro I’ve tried including NixOS. Still haven’t figured out why. - Guix is slow compared to Nix. This is especi…
Guix is also very verbose compared to nix.
Which is a good thing because most users do not want to configure and program Guix stuff all the time. Many will only use it every few months, and probably don't want to learn syntax and semantics again and again.
Extreme terseness like APL or math notation is fine if you work with something all the time. However for infrastructure code and especially build systems, I think readability as well as robustness are much more important aspects.