Guix looks really tempting to me because i find guile scheme so much more pleasant than nix. But i heard there are not that many packages in Guix. I wonder if some sort of transpiler from nix derivations to guix package definitions would be possible.
I've never felt the need myself. If something is missing, I add it and I think that is the real fun in running Guix because creating your own well defined package or service is deeply rewarding.
Anyway, you can find people using it in the wild either by search engine[1] or with Toys[2] which is also handy for finding examples of missing packages too.
You can just visit https://repology.org/ and see that GNU Guix has the 5th largest repository, ahead of Fedora and Gentoo. This does not include any proprietary packages, which can be added using https://gitlab.com/nonguix/nonguix (though gitlab seems to be dying for me right now?)
I've been running GNU Guix for five years now, after lots of distro hopping, including to and from NixOS. I left Nix because I found the documentation (particularly regarding the language) to be a struggle to work with (though I imagine it's improved since then).
GNU Guix + nonguix + flatpak is perfectly suitable for everyday use.
The nix language is maximally lazy. It does not evaluate things it does not need to. This is good because you don't want it to burn CPU building things (very expensive expressions!!) that it will ultimately not need for final derivation. I'm wondering if guix scheme is suited well for this task:
(a) evaluation is eager
(b) lots of variable mutation.
But perhaps lazy evaluation and lack of variable mutation in guix scheme is not such a problem after all for a nix _like_ system -- I don't know.
I'm still new to both Guile and Guix, but I've been reading the Guile and Guix reference manuals recently and I think some of your concerns about eager vs. lazy evaluation of packages are addressed by Guile's quoting mechanism, more specifically "quasiquote" [1]. This quoting mechanism allows passing around references to package definitions and whatnot, without actually evaluating those expressions until build time.
Guix extends quasiquote to create something called "G-expressions" [2], which are even more so fitted to something like the Guix/Nix build system.
Im very familiar with Nix or the language, but why would interpreting guile scheme for package management be expensive? What are guix and nix doing that would require evaluating everything lazily for good enough performance?
I checked the spec and Scheme R5RS does have lazy evaluation in the form of promises using "delay" and "force", but I can see why explicitly having to put those everywhere isn't a good solution.
I don't even disagree that nonfree software is bad, but blaming the users who often have no choice in the matter (e.g. drivers) is the wrong way to go.
nonguix is similar to debian's non-free sources. It's also maintained by many of the same contributors to guix. Enabling it is also similar to how you enable it for Debian. I have never seen anyone blamed or shamed for using nonfree drivers by the guix community, which I can say has been a very warm and welcoming community.
but the attitude has been changing recently from active shaming for even mentioning non-free stuff, to passive acceptance of pragmatically pointing a newcomer to nonguix.
That's good to hear. The intolerance to non-guix (or, possibly, my perception that it was intolerance) made me shy away from the project. This was especially so because I use repaired devices with proprietary HW that would otherwise have been binned by their owners.
we need to speak up for common sense. i did, maybe too much even, and it has cost me some standing with the project lead... but it must be done nevertheless!
people need to understand what freedom means. sure, do inform others about the downsides of using non-free stuff... but it's very hard to help freedom by shaming and alienating people for trying to use hardware they already own.
It's a little inconvenient but for example my Framework laptop Intel WiFi chip requires a binary blob and I want aware of this. Now that I am, I can make better hardware purchasing decisions. There are plenty of alternatives that don't require that blob and it's the only thing I need from the no free channel.
Are there really a lot of alternative Wifi chips that don't require closed blobs? Do you have a list?
Are they found in any laptop that is reasonably available on the market?
I don't think that Guix is punishing users by not supporting non-libre hardware. They are making a choice in what they develop and anybody of similar mind can join their effort.
The nonguix folks are practical. It just stinks that nothing ships with a Wifi chip that doesn't require nonguix pragmatism.
Unfortunately, it's hard to be sure when you buy a WiFi device whether it has the right chipset. Also, most laptops come with Intel WiFi, and that requires non-free firmware.
I really don't think you can gain much realistic freedom going without the blob. The powers that be will never let you have a freely modifiable radio transceiver.
The blob is better viewed as a part of the hardware in this case. What's most likely to happen to get rid of the blob is to just put it on the non-modifiable parts of the device. Viewed in this way, the blob is at least something you can practically inspect, unlike the firmware on the chip itself.
IMHO the stupidest GNU policy is that if a proprietary blob is stored on a flash chip in a gadget, it's ok, but if it's transmitted to the gadget at startup, it's not.
They all run proprietary blobs inside and out. It's ridiculous gatekeeping to say that on the kernel level it's bad, but below it I just put my head in the sand and disregard the millions of lines of closed-source code.
Now if we could just get people to combine Guix and other guile scheme packages that are awesome like mcron into their stacks, and then backfeed more fixes into the ecosystem, we have a real chance at helping GNUland!
I compile nix derivations to well-posed effect/coeffect/graded monad algebra so I can do real bill of materials and build on an action cache engine maintained by professionals, but that's mostly for long-tail stuff.
These days with a la carte access to all of the container ecosystem primitives as nice, ergonomic, orthogonal operations I don't really see the value in nixpkgs. Don't really see the value in a container registry either: a correctly attested content addressable store with some DNS abbreviations is 100 lines of code because mostly it's git and an S3 shim.
The category error at the heart of nixpkgs is that the environment in which software is compiled need resemble the environment in which it executes. Silly stuff. So whether you're a patchelf --rpath ... Person or an unshare --bind-mount Enjoyer (isomorphic), just remember, in 2026 the guy with the daemon that runs as root does not want you to have nice things.
Not distracting at all, it feels nostalgic to me. Id rather have these flashy things than a million popups and registration forms following you around, which is basically the modern web. I hate it so much. This site is pure balsam for my soul.
Here is the latest and in my opinion the best interview with Ed Witten [1]
Things he talks about go mostly over my head. What disappointed me a little bit is that he seems to be a materialist. But that is pretty common position among physicists anyway, so not that surprising.
If materialists disappoint you, then you should check out Deepak Chopra, for all your self affirming quantum woo needs and desires. He will make your dreams come true! Just buy lots of his books, and you both will be very happy.
"But as Deepak Chopra taught us, quantum physics means anything can happen at any time for no reason. Also, eat plenty of oatmeal, and animals never had a war! Who's the real animals?" -Professor Hubert Farnsworth
It's hard to say what "that hard" should be considered, but the book's first half involves Java reflection, which isn't obvious code to port to different languages in my opinion.
Does it? I know it uses metaprogramming (a Java program that outputs another Java program), but that’s probably easier in other languages than in Java. In my Python implementation I was able to significantly simplify that part of the code by using `eval`.
I do remember him using the visitor pattern to implement part of the parser I think. I thought that was kind of an odd choice, especially since it seemed like he was really just trying to avoid Java boilerplate.
Regardless, the book is incredible, and the choice of Java to start with makes sense. Its probably going to be the most universally approachable for everyone, even if they aren't super familiar. C can be pretty overwhelming if you aren't familiar it.
> I do remember him using the visitor pattern to implement part of the parser I think. I thought that was kind of an odd choice, especially since it seemed like he was really just trying to avoid Java boilerplate.
It's used to allow writing a "resolver" and an "interpreter" that both know how to handle every type of node in the AST. It's almost a functional approach, and I actually think it might increase boilerplate because Java is more designed around the object-oriented approach of adding `resolve` and `interpret` methods directly to each node type.
The two approaches result in very different code organisation, though - maybe the visitor approach was easier to explain in prose.
It's been a while since I read it, but I remember him saying something about the more natural (my word not his) approach being a single data structure that you would pass through both components, but he didn't want to do that because Java doesnt really encourage that kind of design, and you have a bunch of boilerplate for each class. It just struck me as an odd choice since the book was more about compiler/interpreter fundamentals, and I feel like the visitor pattern is a bit in the weeds in terms of OOP design.
I wonder if he wrote today if he would have used a Record and done the more straightforward implementation.
I went through the Crafting Interpreters book with modern Java. I posted this on reddit, but I basically used records and sealed interfaces. With modern Java there's no need for visitor pattern.
private void execute(Stmt statement) {
switch (statement) {
case Stmt.Expression expression -> evaluate(expression.expr());
case Stmt.Block block -> executeBlock(block.statements(),
new Environment(environment));
...
public sealed interface Expr permits
Expr.Assign,
Expr.Binary,
Expr.Call,
Expr.Function,
.... more exprs here
Interesting. Almost all my actual experience writing Java is in Java 8, so I'm not super familiar with the modern stuff (other then a few things like Records). I'll have to take a look.
Most of the people I know who write Java would have an aneurysm at seeing a switch statement.
To be clear, that's a critique of the Java mindset, not your code. Lol
It's been a few years now, but there's no real reason to port the Java code directly – you can just read what it's trying to do, and implement that using your language's idioms. I don't remember anything as complex as trying to port reflection.
I understand. I wasn't a Java person when I read that book, yet I still prefer Java over more esoteric options. If Golang is easier for you to understand (no OOP), then I can recommend this one:
Wren, the topic of the post, is positioned as a descendant of Smalltalk, the most OOP language of them all. The author clearly finds the OOP paradigm important.
As I see it, the point of bootstraping a compiler is to develop a compiler in stages and that it doesnt require you to implement the full compiler in the original language.
For example, let's say you create a new language called Brute. You decide to write it in C (original language).
Stage 1: Create a Brute compiler in C, which can compile only a small subset of Brute language. Lets call it bruteC compiler.
Stage 2: Implement a compiler in Brute lang and compile it using your bruteC compiler. This produces brute-compiler executable.
Stage 3: Add new feature to your brute compiler source code and compile it using your brute-compiler executable, which produces new brute-compiler executable.. .
And so on... At the end your brute-compiler supports all language features and thus is self hosted.
Reallly ?
reply