I love Nix. NixOS is my primary development operating system. However, the Nix language itself is syntactically ugly, and this proposal makes it even uglier. Parentheses, sigils and special characters (esp. semicolons) are line noise — the less of it the better.
Why they wouldn't take the most (syntactically) beautiful functional programming language out there — Standard ML? It would work perfectly for such a task. Or the second contender — Haskell. If C-like syntax is desired, the best contendant is probably Swift.
I cringe every time I have to edit a .nix file (and I have to do it a lot).
I love the Nix language and I generally distrust aesthetic feelings about programming languages.
Neither SML nor Haskell are optimized for expressing deeply nested records with many string literals, for example. The multiline interpolated strings in Nix are extremely much better than in SML or Haskell. The way records and arrays are written is great: SML and Haskell both suffer from the tedious problem of using separators between items instead of after each one; in Nix each item can always be moved without messing with separators.
I think Nix is an engineering marvel up to and including the language design. If you can make a better surface syntax and demonstrate it by translating some significant part of Nixpkgs, I'd be very interested, but I think in general the language is the way it is because that's what made most sense for the system's designers.
The only important language is the derivation language sent to the daemon. Nix spends so much time building up inputs... for shell scripts. I always felt like they would have been so much more successful if they chose some other, more popular language to generate derivation.
I dig Guix, but Lisp is also one of the most commonly reviled syntaxes, so it's hard to say it's clearly better, or that Nix would enjoy more adoption with S-expressions.
You'll see here that the package emacs-minimal actually inherits from the emacs package definition, and then all fields afterwards are essentially overwrites of whatever was in the emacs package.
Unfortunately, I just noticed that the manual alludes to this, but actually never explicitly documents it in the "Defining Packages" section :/
No, Nix syntax is much nicer than Javascript. Consider, for example, the similarity between a let expression and an attribute set (NOT JSON by the way):
let
foo = 42;
bar = "a string";
in {
baz = "deja";
quux = "vu";
}
Javascript:
const foo = 42;
const bar = "a string";
return {
baz: "similar",
quux: "but different"
};
You find this kind of thing all over the place. Nix is a much smaller and simpler language syntactically, and more pleasant to write.
I tend to write JavaScript that looks a bit like Nix... but in general, the imperative constructs aren't suitable to the lazy evaluation strategy of Nix.
I may be in the minority, but I like the Nix language.
I don't have extensive ML or Haskell experience, coming from Ruby/Java background.
I think the Nix language works great as a configuration language, and I greatly prefer it to JSON, YAML, or Ruby, which are often used for similar purposes. The way arguments are passed in, merging of attribute sets, the library from Nixpkgs with various list and set operators and other utilities, and great multiline string support make it far superior to those other config languages in my opinion.
My biggest gripe is that the Emacs mode isn't very strong, so I'm often applying indentation manually.
I recently learned about Jsonnet[1] which has some similarity with Nix.
I could not agree with you more! I use nix daily, and every time I go to edit it a nix file a voice in the back of my head says, "you should really start that Haskell to Nix compiler you've been thinking about."
[edit] ha! just notice the next comment talking about hnix. Great minds... :)
oooh but this is one of those trivial things that I really liked in my brief days of using Haskell, and that has sometimes carried over to my C++, e.g. in initializer lists. I find it super useful because everything lines up nicely, and from the point of view of version control you don't have to edit the previous line to change '}' to ',' when adding a new line.
Yes, when the commas are at the beginning of the line they are really obvious. I have used commas-first style in JavaScript, and it definitely reduced the amount of times I forgot a comma.
I wonder if people's aversion to commas first has something to do with the fact that commas have a very familiar use in ordinary writing, and there they always follow a word. It is very common to see BNF grammars written with leading vertical bars, and no one seems to mind that -- in fact it would be unusual to use trailing vertical bars.
By the way, a bunch of languages permit a trailing comma after the last element of a list. This is also nice because it means that if you put each list item on a line, the list items all have the same format (thing plus comma). With the Haskell syntax, you lose this, but there is no reason a language couldn't support a leading comma before the first element of a list.
My aversion has to do with the fact that the first element doesn't have one. The irregularity is annoying not just aesthetically, but also if you want to swap lines around, etc.
But there's always a line without a comma -- comma-last has it on the last line instead of the first. So you can have the same line-swapping problem in either arrangement. Comma first just makes it easier to spot.
Not if you allow dangling commas (trailing commas as the sibling comment calls them, I think it's the more generic term)...
Then you have a comma at the end in ALL lines, including the last one, without an issue. That was what I proposed above (and lots of languages do it, I think JS is adding it too).
It's another thing to learn, and the total learning curve is the product of all of these idiosyncrasies (and features) (not the sum). And there's absolutely no advantage to comma-first.
This is only true if you insert at the head. And it's not really leading comma placement but the choice to put the first element in the line with the brace that is the culprit, though both are typical of comma-first.
With separating comma, it either affects the first or the last position, depending on where you put the commas. But those are the most common places you modify lists.
Wow, I'm doing the opposite where I'm staring at all these other DSLs and configuration files and have to hold myself back from writing a bunch of nix to autogenerate them from.
Haha same here, I've been considering writing Nix expressions for window manager configurations for quite some time now, but some config files are so complex that it would take ages.
If I only look at the language properties then Nix makes sense to me. The fact that Nix is lazily evaluated allows for easy composability. This is used a lot in nixpkgs to allow overrides and build up packaging layers. And because the language is interpreted, only the files that are being used need to be evaluated. It wouldn't be very practical to hold all of nixpkgs in memory. It also allow to do things like dynamically import code from another git repo. And finally, the language only allows side-effects through derivations.
None of the above language have all these properties combined.
It looks like someone threw a pinch of erlang in a Chef recipe. Like bash, but every English word operator has been replaced by space ships, angry squids, ternary operators, && all the other things that make code hard to read.
I have no idea why you would think that. It's pretty standard usage of punctuation like (){}[] etc. If it's hard to read that's because the libraries and infrastructure for writing derivations is not simple or well-documented. But that's not a language issue.
Hi, author here. While I agree that the language could be improved, I wonder why you say that this makes it uglier, and how you'd imagine a better solution (this is still in development, and any idea is welcome).
Unfortunately no, except maybe for some very minor tweaks that have a chance to be included in vanilla nix, but otherwise this would most probably either mean the death of this project or a split in the (already small) community, which I both don't want to see
The only place where I think we could make the semicolons optional is at the end of a let-binding or a record (like json does iirc), which would indeed be a small but blessed change.
For the array litterals, I don't really see which improvements your syntax brings (except suppressing the space-separated list, which conflicts with the syntax for function application). Is it used somewhere else ?
(I can't reply to the previous message regarding no-semicolon syntax, so I have to do it here. I definitely do not want to propose whitespace-sensitive syntax — just newline-sensitive, like in Scala, Swift, modern ECMAscript, or just any modern programming language with C-like syntax. Semicolons are allowed, BTW — they are just optional and inferred from newlines).
Very strongly agreed. Syntactically significant whitespace is the source of so many preventable errors that I believe it's simply not worth the aesthetic improvements.
Keep in mind that I am being simultaneously irreverent while also expressing how I feel about these two debates (semicolons and significant whitespace).
I'm someone who has worked in a large variety of languages, including Python (significant whitespace) and Javascript (no significant whitespace).
First: semicolon inference in Javascript is an abomination :). If the language says that whitespace is not significant, then using newlines to infer where semicolons maybe should be... is inconsistent with the statement "whitespace is insignificant".
Second: when I learned Python, I was coming from a primarily Perl and C background. The significant whitespace wasn't a big deal at all because that's how I indent my code anyway. And I would argue (and do in code reviews) that any code that is not indented properly is incorrect because it is extraordinarily misleading to a reader.
So, yeah, for any given programming language, I couldn't care less if whitespace is significant or not, or whether there's semicolons at the end of lines, but god damnit don't go half way on either of those. Indent your code as if whitespace is significant (because it IS to whoever's trying to decipher it later), and stick semicolons at the end of your lines whether or not some stupid inference rule will stick them there for you if you forget.
And as a final rant, "modern Javascript" didn't introduce semicolon inference; it's been there for a long time and was put there to try to lower the barrier for newbies. It wasn't put there because it's a great design decision.
I come from Scala, and there semicolon inference works flawlessly. Why do you consider it to be an abomination in Javascript? (Except this famous corner case with continued line, almost never encountered in practice).
Things like this[1] are why I dislike semicolon inference. I very much think in language grammars, and languages that do clever things on top of that tend to annoy me. And, yes, I realize significant whitespace is likely implemented as a an edge case outside of the grammar, but it's at least simple.
An interesting thing with Scala is that in the BNF, "semi" is defined as ';' or nl.[2] After doing some initial reading about Scala, I was pretty much wondering why Scala needed semicolons at all. What you call "semicolon inference" seems like it's more like "optional semicolons", in that the language doesn't really need them.
Well... This is a sort of whitespace sensitivity, and I don't really like it, because that means that some tokens may or may not be meaningful depending on the context, which increases the complexity of the syntax -- and syntax is probably the first thing that I think should be dumb simple and predictable.
Is that a definite no, and there's no chance of compiling whatever $newLanguage is written to the current nix code prior to execution?
If that was possible, and a few $000 was raised (looking at the comments here, I think people would chip in) then a new version of the Nixlang with the same semantics and full backwards compatibility but a cleaner syntax, would be a great project to fundraise for.
Can't it just accept two different syntaxes (if really necessary for disambiguation, perhaps requiring people to put some magic string at the beginning of the file to request the new syntax)?
Aside: I would love it if ML caught on. Such a good balance between expressiveness and usability. Imagine if Caml had caught on in the 90s instead of Java...
This is why I'm very much interested in Guix and GuixSD, which use Guile Scheme. Unfortunately I don't think they have an officially-supported story for running on the server, yet, or an equivalent to NixOps.
I need CUDA drivers for what I am working with, and I have found no way to install it in Guix. Otherwise, it looks interesting enough.
(Sexps are usually not my first choice, I think it is a "lazy option" for people who do not want to write parsers / design their own syntax. Even then, they are better than current Nix expressions).
> Sexps are usually not my first choice, I think it is a "lazy option" for people who do not want to write parsers / design their own syntax.
There are some real advantages to having one universal syntax: witness the explosion in XML and, later, JSON (both of which are generally inferior to S-expressions[1]). It'd be pretty great for one person to write one parser, and then everyone forever after to be able to use it. We'd be able to focus on semantics and not on syntax.
[1] Although it is nice that JSON supports first-class associative arrays.
AFAICT, there are 2 major differences between Nix and Guix. Language choice is the obvious one. The other is that Guix takes a hard-line stance on the GNU philosophy and therefore refuses to distribute pre-compiled binaries. I don't think CUDA will ever be an option on Guix.
Does something actually stop you packaging proprietary binaries, perhaps privately, for Guix? It's clearly better to say No, but CUDA is a case where that's difficult.
(I don't see what's wrong with adopting sexps to avoid dealing with custom syntax -- quite the opposite,)
OK, there's a distinction between the GuixSD free software distribution and Guix package management. I'm surprised you can't build and use a non-linux-libre kernel with GuixSD, though; that presumably excludes even free additions, like Lustre, unless someone has done the forward porting work. (One of the recent HPC-ish presentations on Guix mentioned nvidia stuff -- I don't remember which.)
Some academics say that sexp allow to focus on what's important: semantics. I kinda agree with that, so many time, effort is wasted on syntax that moves, and only make ideas further apart.
Well, right, but we are not talking about an academic paper here, we talk about practically convenient language. If syntax is unimportant, we could leave Nix files as is -- semantically, it is a good programming language. But judging from the comments, I am not the only one who thinks that syntax and overall esthetics are important.
Really? I write almost nix every day at work and I have no problem with the syntax. I think it's pretty elegant and well-suited to its use case. There are a few minor tweaks I would make but nothing big at the syntactic level.
EDIT: probably the only gripe I would make is to have comma-separated lists instead of having to use parentheses to separate non-atomic expressions.
> I cringe every time I have to edit a .nix file (and I have to do it a lot).
No need to cringe over syntax. Syntax is just syntax. If you are familiar with a better syntax to express Nix in then create a parser from that format to Nix' syntax. Then insert this parser as a pre-processor in the build process, and problem solved.
Honestly that's the only thing that keeps me from jumping to NixOS. I don't want to learn a weird language, I'll never use for anything else, just to maintain my OS.
The language is so simple you can learn all of it in a day. Read through chapter 15 in the nix[1] manual and that's it.
To me it doesn't feel weird at all: I can't think of any feature that was new or surprising when I started using it and I am not the biggest expert of functional programming. You have to learn more about the standard environment and tools if you want to start contributing to nixpkgs and write your own packages but if you only care about configuring your system nix is as difficult to learn as say, JSON.
Personally, I'm not against the idea in principle. There are some real DSL-haters out there, and I'm not one of them. For a different problem domain, a different language can be more efficient.
It's true that some DSLs are not only different, they're also badly-designed languages or gratuitously different. I guess this is an occupational hazard of DSLs, but it's not unavoidable. It's possible to make the leap to a DSL only when actually beneficial and then to design a DSL that doesn't suck.
Why they wouldn't take the most (syntactically) beautiful functional programming language out there — Standard ML? It would work perfectly for such a task. Or the second contender — Haskell. If C-like syntax is desired, the best contendant is probably Swift.
I cringe every time I have to edit a .nix file (and I have to do it a lot).