Here, my summary of key features and decisions of Guix:
- Guix is a package manager that can (optionally) run on top of Linux distributions or other POSIX systems, like cargo, pip, conda or Conan. In difference to the pip and cargo package managers, it is language-agnostic, supports many different build systems and languages, and features around 29000 packages now.
- Guix allows to define a fully reproducible system. This works by using a declarative language for immutable version-controlled package descriptions, and by deriving any software from package definitions and a fixed version (commit hash) of the source code. In that, it is similar but much stricter than Nix and NixOS. The key point is that any software built, and all its dependencies, go back to unambigously, immutable versions of source code and build recipes - and all inputs to the system are open source and can be reviewed.
- Important for programming, this can also define isolated build and development environments, like Python’s venv, but also Docker containers. This means that Guix can be used to develop, build, package, and deploy software, very much like Snap packages. And that’s independent from the distribution you work in, very much like pip or cargo are independent from the system you work in. (And yes, it supports Rust!).
- This allows it, and also makes it technically possible, that any software package can be re-built and run years later. To make this legally possible, the official distribution of Guix also demands all components to be open source (FOSS). This is also a key difference to NixOS and non-free forks of Guix, which allow non-free binary packages, but sacrifice reproducibility. (To illustrate: If you have a binary, proprietary scanner driver in NixOS, and the owning company practices planned obselescence and decides that you should buy their new hardware, and pulls that driver, you are out of luck. In Guix, this can’t happen.) (Note that as your own private conponents, you can define any package you like, you can also distribute your definitions as a complement to GNU Guix. Non-free packages for Guix do exist, in the same way as you can buy and run Steam Games software for Linux. Such non-free software just can’t become part of the official Guix distribution, just like Amazon or Apple can’t sell their non-free software via Debian or the Linux kernel project (or, for that matter, Apple has no obligation to market and distribute, say, Oracle products).
- All inputs being open source also means that any software component can be reviewed, that mis-features such as privacy-invasive behaviour can be removed, and that it is hardly possible to hide malware in the system. Because this also applies recursively to all compilers and build tools, this solves also Thompson’s “Trusting Trust” problem. In fact, the whole system can be build from a 512 byte binary root (called MER). (Interestingly, that level of user control gets a lot of hate online – certain companies don’t seem to like it).
- Because it would take too long to build every user package from source every time, the produced packages are normally cached (while their correct binary content can be easily verified).
- The declarative description language for the packages is a well-defined, established, minimalist language called Scheme. This is a member of the Lisp family of languages. That Lisp is very well suited for declaratively building and configuring large systems has been proven with GNU Emacs, whose software, but more importantly, whole user configuration, is written in Emacs Lisp.
- The Scheme implementation used is called Guile. It has especially good support for the POSIX environment and has also much better-than-average interactive debugging capabilities compared to other Scheme implementations.
- Also worth noting is that the Guix project has superb online documentation. This is a practical advantage compared to Nix.
As example: you are on Debian stable and quickly want to try a recent version of the kakoune editor (as kakoune is in ongoing development): They are available under the Guix package manager. Just
guix install kakoune
and bang you have it!
How it works:
https://codeberg.org/guix/guix#headline-4
Manual:
https://guix.gnu.org/manual/en/html_node/Installation.html
Also informative for using Guix just as a package manager:
I think python’s ternary expression descends from C’s with a different order, rather than from LISP, at least as far as I remember.
The key point here was not the exact syntax but the functional style. The ternary conditional operator, regardless how it’s written, is for sure functional style because it is an expression.
And, it is sometimes objectively better to write
than
because functional style is clearer in such cases.
Back to topic: Guix und Nix are pure-functional package managers, and Guix uses a (mostly) functional package declaration language, Scheme, because it works better.
Can you present a convincing argument why you think that?
BTW Python’s if-expressions are a bit weaker than C’s. In C, you can write:
in other words, the result of the ? operator works as lvalue, that can be assigned to. In Python, this isn’t the case.
because it’s
k if cond else j, notif cond k jBut in C comes first the condition, then the then-expression, then the else-expression. The same is the case for Lisp / Scheme. It is Python that is different here by putting the condition in the middle, probably to become more similar to a natural English form.
The PEP describing the background to the introduction of python’s ternary operator refers a fair bit to C, contemplates using C’s syntax, and doesn’t refer to functional languages.
It would be hard for me to prove that the authors of the PEP were not motivated by C (though the ? ternary operator stands out in C like a sore thumb, it is highly unusual for C as a whole, and it seems that it originated in Algol 60, a predecessor of C). Proving this would require a fair bit of software “archeology” or software history research, given that Lisp is from 1960 and C from 1962.
According to Wikipedia, Python was originally influenced by ABC, Ada (?) ALGOL 68, APL, C,C++, CLU, Dylan, Haskell,Icon, Lisp,Modula-3, Perl, Standard ML. Of these, at least 5 (APL, Haskell, Lisp, Dylan, and Standard ML) are functional.
But what I think here is that the text of that PEP 308 is not a scholar work of software history research. Its goal was to convince the audience, and the main audience were the Python contributor community. And the leader of them was Guido van Rossum, who is well known for not liking functional programming (in Python 3, the
filterreduce function was removed because of that). And van Rossum was one of the two authors of the accepted PEP.Not sure why you replied a second time.
You don’t have to prove a negative; you can just read the PEP and see that C is mentioned and lisp is not. In the mailing lists, people often discuss the C-like syntax. Nobody proposes turning the entire if statement into an expression.
Anyway, I’m not sure if the edit to your original comment affected this, but I didn’t mean to argue that python didn’t draw any inspiration from functional languages. What I recall was an implication that its ternary expression descended from if statements in pure functional languages, which I don’t believe to be the case.
And how about lists, map(), lambda(), closures, the numerical tower from arbitrary-sized integers/rational numbers/floating point numbers, list comprehensions, generators, and pattern matching?
I don’t think Lisp invented lists
But in Lisps, lists are the standard indexed collection data structure, and the same is true for Python. Actually, arrays are part of the Common Lisp standard, while they were not present in original Python 2, and were added as a numpy/Numeric extension.
Lisp is (elegantly IMO but also in a way that makes it intimidating to read) indeed built on lists. I do not see how that makes Python’s lists have any relation to Lisp.
Python lists are in fact (and as far as I know, always were) resizable arrays. NumPy arrays are arrays with certain useful extra functionality.
Yeah and numpy got a lot of its inspiration from APL, a functional language. Konrad Hinsen, an important early contributor to numpy, wrote in his blog avout that.
I don’t know how any of those relate to from where the ternary operator drew its inspiration.
I’m sure python drew some of its functional features from lisps, but ternary expressions aren’t particularly functional so it shouldn’t be controversial they came from elsewhere.