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

Guix for Development

dthompson.us

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Guix for Development

#31

Post by helibom »

sidkshatriya wrote: post #25
smnplk wrote: post #4

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.

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

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.

1. https://www.gnu.org/software/guile/manual/html_node/Expressi...

2. https://guix.gnu.org/manual/1.5.0/en/guix.html#G_002dExpress...

Re: Guix for Development

#32

Post by rudhdb773b »

I love Guix documentation, but unfortunately I've had to stick with Nix because its more polished with a large library of packages.

LLMs have also made writing syntacticly correct Nix scripts much easier, so I don't miss Guix's Guile that much.

Re: Guix for Development

#33

Post by allan-a »

digiown wrote: post #6
whompyjaw wrote: post #5

Earlier quoted context omitted.

Im with you. As an emacsen, i feel it’s natural for me to use Guix, but nix is so so much more popular… :/

Guix being a GNU project the purism also doesn't help. Just look at this: https://github.com/nonguix/nonguix 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.

Re: Guix for Development

#34

Post by tetris11 »

I love Guile over Nix syntax, but the one killer feature Nix has that Guix doesn’t is making a single static binary of common programs and then deploying them elsewhere.

In Nix, this is a single flag. In Guix, you either deploy with all libraries on a custom /guix path, or nothing.

Re: Guix for Development

#35

Post by dhon_ »

tetris11 wrote: post #34

I love Guile over Nix syntax, but the one killer feature Nix has that Guix doesn’t is making a single static binary of common programs and then deploying them elsewhere. In Nix, this is a single flag. In Guix, you either deploy with all libraries on a custom /guix path, or nothing.

How do you do it in nix?

Re: Guix for Development

#36

Post by Hasnep »

atiedebee wrote: post #28
sidkshatriya wrote: post #25

Earlier quoted context omitted.

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

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?

It's not the Nix/Guile that's expensive, it's situations like:

    let chromium = pkgs.chromium; in 1 + 1
In a maximally eager language you'd need to wait for the entirety of Chromium to build before you can find out what 1 + 1 is.

Re: Guix for Development

#37

Post by atiedebee »

Hasnep wrote: post #36
atiedebee wrote: post #28

Earlier quoted context omitted.

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?

It's not the Nix/Guile that's expensive, it's situations like: let chromium = pkgs.chromium; in 1 + 1 In a maximally eager language you'd need to wait for the entirety of Chromium to build before you can find out what 1 + 1 is.

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.

Re: Guix for Development

#38

Post by otabdeveloper4 »

esperent wrote: post #16

> Dockerfiles are clunky and the rather extreme level of isolation is usually unnecessary and makes things overly complicated I agree, for local development docker is often overkill. However, for production it's absolutely not overkill. And since pretty much all projects are intended for production at some point, they'll need a Dockerfile and docker compose or some other equivalent. And at that point, you're maintain…

You'd be nuts to run the Docker daemon anywhere near production.

Re: Guix for Development

#39

Post by attila-lendvai »

goranmoomin wrote: post #17

I feel like declarative container-like dev environments (e.g. nix shell or guix shell, and so on) will become much more popular in the following years with the rise of LLM agentic tools. It seems that the aformentioned tools provide much more value when they can get full access to the dev environment. Sprites[0], exe.dev[1], and more services seem to be focusing on providing instant VMs for these use cases, but for m…

random note: there's `guix shell --container --emulate-fhs`.

Re: Guix for Development

#40

Post by attila-lendvai »

sidkshatriya wrote: post #25
smnplk wrote: post #4

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.

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

"lots of variable mutation" is more like "variable mutation is no impossible, but not common".
Post reply on HN