[vluft]

nix & nixos are by far the worst way to manage system configuration, except for any other way that's been tried. imagine if there was something with declarative system configuration _not_ written in an insane undebuggable recursive nightmare of a language/stdlib? oh well, I'll keep using it, because what other options are there?

[gausswho]

guix would like a word

[sidkshatriya]

+1, Guix is quite good with some tricks up it's sleeve compared to Nix.

I am not a fan of S-expressions but using scheme is more reasonable than nix+bash to me.

On the negative side, guix can be slow. It is also not a very pragmatic os. NixOS does non-free firmware and drivers without issue. You need to jump through some hoops for this with Guix. This is not an issue if you plan to run guix in a VM though.

[accelbred]

Does guix have a flake equivalent yet?

[ulbu]

different ui. you can pull in different commits of channels (packages repos) and take packages from them. but it’s opt-in, no lock-file snapshots.

https://guix.gnu.org/manual/1.5.0/en/html_node/Inferiors.htm...

[accelbred]

The lock file is the major feature I'm missing.

[rowanG077]

I mean it's pretty wild to take s-expressions and not call them extremely terrible to read. The nix language sucks really badly, but I gladly take it over writing S-expressions.

[Pay08]

It reads almost the exact same as any functional C-style language. Not to mention that specifically for Guix, you're going to be writing the (name value) form for 99% of it.

[grumbel]

> you're going to be writing the (name value) form for 99% of it.

That's exactly the part that is wrong with Guix, and Scheme in general. Scheme has associated lists, they are written as '((name . value) ...), but since that's too ugly everybody makes macro wrappers around them to get them down to just (name value). But that means you aren't dealing with an obvious data type anymore, but with whatever the macro produces and if you want to manipulate that you need special tools yet again. And then you have record-type and named arguments which are different things yet again, but all serve the same name->value function as an associated list. Names themselves are sometimes symbols, sometimes keywords, and sometimes actual values. Same with lambda, sometimes you need to supply a function, other times there is a macro that allows you to supply a block of code.

It's like the opposite of the Zen of Python, there are always three different ways to do a thing and none of them as any real advantage over the other, they are just different for no good reason and intermixed in the same code base.

[Pay08]

I have never seen anything else use the (name value) syntax. You do deal with obvious data types, the REPL tells you exactly what those data types are (records, in the case of Guix). Schemes outside of Guile don't even have keywords, much less named arguments.

Are you complaining that a language has both associative containers and structs? Which one do you advocate for removing in Python to keep up the precious "Zen"?

[rowanG077]

I don't agree at all. Just look at these derivations: https://codeberg.org/guix/guix/src/branch/master/gnu/package...

I counted and you regularly see this: "))))))))))" at the end. This is not a language that is optimizing for being written by humans.

[globular-toast]

Lisp programmers have used editors that count the parens for them for decades. Many use something like paredit that simply automatically adds the final paren. I've written significant amounts of Lisp and you simply don't see the parens. You might as well complain about French having all those accents. It's just a different language. Learn it and you'll see why.

[rowanG077]

I can write lisp. That a lot of lisp programmers require special editors to handle it should tell you enough. It's not that the language is unworkable. You can definitely write stuff in it. The point is that it is quite far from something that should be written by people, in my opinion.

[bjoli]

Which is the most tired critique of lisp ever. Even the text editor on my phone can keep parens balanced for me.

S-expressions were supposed to be replaced by a more user friendly syntax. The trade offs were not worth it and every try to replace sexprs failed.

If it is such a problem you can use wisp to write your packages.

https://www.gnu.org/software/guile/manual/html_node/SRFI_002...

[rowanG077]

Most code is read much more than it is written, at least I read much more code than I write. So for me code should be optimized to be read as plain text as that is basically what every tool uses. Requiring a separate tool to get basic readability is not really acceptable. I can't do that on github, I can't do that with the various diff tools, I can't just quickly cat a file or use the countless other tools that are designed to present plain text.

If I then can choose between guix and a language that doesn't require these hoops and extreme quality trade off the choice is not hard.

Anyway if you think guix is better than nix, than nothing stops you from using it.

[troad]

> This is not a language that is optimizing for being written by humans

I've taken a look at the code - having never written a line of Guix in my life - and it seems very readable to me. It's cleanly structured and makes good use of indentation.

The string "))))))))))", which you claim you're seeing 'regularly', appears exactly twice in 4,580 lines of code. It's the longest parens string that appears in the file. Seems to me like you deliberately searched for the most atypical example, that you're now misrepresenting as 'regular', when it is highly atypical.

And honestly, what would that look like in some 'more normal' language?

              );
            }
          );
        ];
      };
    )()();

Better?

I will never understand this fear response some people have to seeing `(fn a b)` instead of `fn(a, b)`.

[rowanG077]

I indeed searched for the longest chain. Something that happens in 4.5k lines twice is hardly rare. And even if you take away a brace it occurs even more frequently.

And yes your example is better, but still terrible. The point is not the formatting. The point is that there is that 10 deep nested code is just not easy to understand. I would also say a line of c/python that does 10 nested function calls as unreadable. But they do not encourage this, whereas with lisp its modus operandi to write such incantation.

[Pay08]

That link isn't working for me (something about AI detection), but as a point of accuracy, those aren't derivations, they're simple source files. Derivations are generated out of them.

As for the closing braces, would it be better if you had a newline between each?