[atemerev]

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).

[mbrock]

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.

[codemac]

> If you can make a better surface syntax

... http://gnu.org/s/guix

Lisp is pretty good at lists.

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.

[mbrock]

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.

[wcummings]

Reviled by people who have never used it.

[gkya]

Most commonly and with lots ans lots of prejudice.

[jancsika]

Is it possible to write a guix package that includes code which redefines the package object?

[codemac]

Yes!

http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/...

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 :/

[KirinDave]

> Neither SML nor Haskell are optimized for expressing deeply nested records with many string literals, for example.

Purescript's extensible row types handle this process elegantly and if Nix takes a cue from that, it will work great.

[qznc]

So, JavaScript? The records literals are JSON, which is the most popular syntax for this at the moment anyways.

[cwp]

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.

[mbrock]

Also, recursive definitions using "rec" which become nasty in JavaScript.

[mbrock]

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.

[pmahoney]

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.

[1] http://jsonnet.org/

[dtwhitney]

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... :)

[regnat]

You might be interested in dhall[0] and dhal-to-nix[1] which provides a really neat haskell-like language that compiles to nix.

[0]: https://github.com/Gabriel439/Haskell-Dhall-Library [1]: https://github.com/Gabriel439/Haskell-Dhall-Library

[atemerev]

If only Haskellers knew that "a blog post" and "type definitions in Hackage" are not documentation...

Also, the comma-first syntax like

{ foo = "bar"

, baz = "qux"

}

drives me nuts. In the name of all good things in the world, why?

[radarsat1]

> comma-first syntax

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.

[weberc2]

Go solves this problem by permitting

    foo := Foo{
        x: 10,
        y: 24,
    }

[mercurial]

Also Perl, Python, Javascript and Rust.

[teddyh]

Python does this, too.

[coldtea]

How about allowing for bloody danging commas?

[wereHamster]

Is there any real disadvantage to comma-first, other than aesthetics (which is entirely a personal preference)?

[ben0x539]

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.

[nv-vn]

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.

[zimbatm]

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.

[atemerev]

I am only talking about the syntax. Semantically, Nix absolutely rocks.

[jajern]

It's one of those languages that a developer can look at and think "Oh, so this is how non-developers see code".

[joombaga]

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.

But... I still love Nix, and you get used to it.

[atemerev]

Bash is still worse. Probably. I know it is ubiquitous, but if I can avoid writing Bash scripts, I do.

[kmicklas]

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.

[regnat]

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).

[atemerev]

Is there any option to break source-level compatibility? (Automatic translation to old syntax will still be possible and seamless, of course).

If yes, I can draft a proposal.

[regnat]

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

[atemerev]

Community could be larger if all these petty things were resolved :) But I understand, forking is definitely not an option.

So, if only gradual changes are allowed, I would have started with:

- making semicolons optional

- commas for implicit array literals (e.g. "a", "b", "c" in lieu of ["a" "b" "c"]

- something to do with 'with' / 'in' syntax.

In fact, I can live with anything, except non-optional semicolons. Is there a possibility to infer them?

[regnat]

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 ?

[atemerev]

(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).

[atemerev]

Here is the example where I just removed every semicolon.

https://gist.github.com/atemerev/889806081ed8fcb77495666fac9...

For me, it looks infinitely better.

[tonyarkles]

> In fact, I can live with anything, except non-optional semicolons. Is there a possibility to infer them?

I'm genuinely curious... what makes that a dealbreaker?

[atemerev]

Just look:

https://gist.github.com/atemerev/889806081ed8fcb77495666fac9...

[porker]

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.

[ykler]

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)?

[regnat]

My tool could, but (for now, at least) it is a separate project from the main Nix interpreter, and this one is notably slow to evolve

[adultSwim]

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...

[mintplant]

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.

[agumonkey]

You tried guix ? I still have a fondness for sexps, but ML would be nice too.

[atemerev]

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).

[zeveb]

> 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.

[corysama]

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.

[geokon]

Pretty sure there is nothing language-wise stopping anyone from hosting a separate repository with pre-compiled binaries.

It's a volunteer-run service. It makes sense they don't want to host your proprietary binaries

[gnufx]

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,)

[wcummings]

The kernel it ships with won't load blobs.

[gnufx]

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.)

[agumonkey]

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.

Anyway, thanks for the answer

[atemerev]

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.

[thinkpad20]

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.

[kmicklas]

> probably the only gripe I would make is to have comma-separated lists instead of having to use parentheses to separate non-atomic expressions.

Wait no separators are evil. This is the best thing about the syntax.

[runeks]

> 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.

[KitDuncan]

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.

[rnhmjoj]

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.

[1]: https://nixos.org/nix/manual/#ch-expression-language

[atemerev]

It is definitely not difficult to learn, just somewhat hard to read and visually unappealing :)

[adrianmonk]

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.