It's been a while since I used NixOS, but I never really had an issue with the language. What was frustrating was in package solutions there were all these special functions which as far as I can tell were undocumented and I couldn't figure out what they could do. So there was sort of this gap in terms of documentation between theoretical understanding and tooling/functional understanding which I struggled to cross.

As someone 8 months into a major Nix packaging effort (1200 package definitions, mostly auto-generated), this is 1000% the most significant issue. Reading the pills can get you the first little bit, like the difference between derivation and mkDerivation, but so much later stuff is just completely undiscoverable and inconsistent, like the fact that overrideAttrs may subtly not do what you want if it's a Python package since you have to use overridePythonAttrs instead, but the corresponding function for other builders (eg overrideBazelAttrs) doesn't exist.

This is indeed not very good. Note there is a reason that overridePythonAttrs exists: it overrides the call to buildPythonPackage instead of mkDerivation. There is/was an RFC on standardizing overriding in Nixpkgs but it got stuck. I think for these things to improve what is really necessary is funding to improve Nixpkgs. These kind of issues are fairly hard to solve as they span multiple ecosystems and require coordination.

Oh, of course, and in my case it was an important discovery, because my custom packages were all also defined in terms of my own mkDerivation-wrapping function, so I happily copy-pasted the definition of overridePythonAttrs to make my own overrideMyAttrs version of it.

But it was brutal that I had to just stumble across this. I think the article correctly identifies that there is decent enough documentation in Nix for:

- Beginners to the nix language/concept (Nix Pills)

- Beginner users of NixOS (the NixOS manual)

- Beginners to packaging for Nix (wiki articles, blogs)

But there is a huge, huge gap for the user who is trying to cross the chasm and become a true expert in it all— who wants to understand at a deep level things like how overlays and namespaces work, how bootstrapping works and what is the division of responsibilities between nix and nixpkgs, plus the inner workings of things like buildEnv and stdenv.

I mentioned it already below, but just to emphasize: I think Burke Libbeys playlist on Nix [1] is that missing piece. It lays down a solid foundation of understanding on what Nix is both conceptually and syntactically. You are then able to derive the rest of the needed understanding by clicking through the nix source of whatever it is you are trying to figure out.

[1] - https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...

As someone who really likes the idea of declarative system configuration and management, shares the vision of nix and guix, and have been dipping my toes by using nix package management on macos (and sharing most of the experiences mentioned upthread):

I do thank you for the pointer, and I think I've come across these videos before, _but_ to me, video is probably the last format I can assimilate this type of information. Usually, in my experience, well designed systems have a way of making sense so that documentation and understanding flows naturally from base abstractions, and this is something I miss in nix. I would like to try guix to see whether that makes more sense to me, but I am hesitant given that nix seems to have so much more of the mindshare.

One day I'll try to give the video tutorials a chance, maybe it will clear things up. Thanks again and thanks to mr Libbey as well.

> well designed systems have a way of making sense so that documentation and understanding flows naturally from base abstractions

Honestly, thats the main revelation I had when going through that playlist. Basically Nix is just attribute sets (which is sort of just a JSON object). The entire thing. Nix files are just some preamble and then they return an attribute set at the end. Understanding that will get you 90% of the way there in terms of understanding the syntax and being able to cut through the "weirdness".

At that point its about understanding actual concepts like overlays, derivations, etc but its much easier now that you understand the attrset concept.

I hear you, I think I understand what you mean and I definitely want to believe you, but how come this can't be explained in a succinct written documentation, instead of a series of video tutorials by example?

I do realize it's a work of passion done by numerous volunteers, to whom I feel gratitude, but at this point, why can't this be adequately defined, in a written form, in a way that is understandable? To me, the concept of a series of projections of declarative configuration statements onto a final state is not hard to understand in itself; yet, I am somewhat struggling to create and maintain such a configuration without feeling that I am just copypasting bits and pieces from random people.

I guess I just have to bite the apple and spend a few days watching YouTube to see if I reach enlightenment - at this point, I barely understand the function names.

Yeah like I said, I struggled for a couple _years_ on having a feeling of complete confusion when copying a shell.nix to every project I spun up. I was never able to understand _any_ of the written documentation. After that playlist I easily click through the actual nixpkgs repo itself and find almost everything I need to handroll my own derivations.

It seems like the community is just a bunch of people who have had that lightbulb go on already, so its hard to go back and view things without the lightbulb on.

The language reference worked out fine for me but the chasm between "basically running" and "knowing what I'm actually doing" has been substantially painful and I'm still not on the other side.

Though I say this while continuing to slog through said pain as I find time because once I've learned a particular thing it's always felt like it was worth the effort to get there.

100% this. The language is designed for its use case which is packaging and configuration (nothing more or less). It has a learning curve due to being lazy and functional but works great once you get the hang of it. But the documentation of all its functions is so annoying. You have builtins and the nixpkgs functions[1]. There is learning the language, and then learning how to use it. Then there is the entire ecosystem of custom packaging functions that have their own pros/cons [2]. The issue isn’t with the language but the difficulty with trying to make existing tooling work the Nix way. That part is where I agree with the curse of nix. But the effort is worth it because once the packaging is complete it just works (forever).

1: Best resource I’ve found is this: https://teu5us.github.io/nix-lib.html

2: The status of lang2nix: https://discourse.nixos.org/t/status-of-lang2nix-approaches/...

However, until this works, nixpkgs should provide a wrapper around FHSUserEnv which allows developers to develop without the curse.

Convenient (version-addressed!) FHSUserEnv is exactly what I want out of Nix. Land me in an environment that has a list of deps (at specific versions, not hashes!), let me go mess with it.

These look pretty promising. Maybe I'll give nixOS another shot because I really was a big fan.

The best way I’ve found around this is to always keep a local clone of nixpkgs so that I can grep for where functions are defined and hope like hell that there are some comments in the vicinity. Definitely not ideal.

If you're using Nix on your system, you can also find nixpkgs symlinked under ~/.nix-defexpr/channels/nixpkgs/pkgs/ or so.

And if you have flakes and nix-command enabled, you can run `nix edit nixpkgs#lib.sort` to get the definition of the sort function.

(This will just tell you it's imported from lists. `nix edit nixpkgs#lib.lists.sort` will get you the actual definition.)

Nice, I did not know this. Thanks!

What really helped me were the videos of Jon Ringer: https://www.youtube.com/user/elitespartan117j27

Glad someone found them useful :)

I cannot thank you enough for these. It is so much useful to see someone doing a task.

I believe what Nix really, really needs. Is to separate all the lib, builders and frameworks for languages need to be separated out of it (probably into separate repo, maybe even repos), and treat it like a stdlib is treated in any other language.

That means, it can't be just modified by anyone on a whim, all of changes need to be done through proper RFC mechanism. And anything in it must be documented.

Having all that done would greatly improve learning time, it would probably make it easier to maintain other packages as well.

It made sense that it was done this way originally, because initially no one knows what would be needed, but right now many things are solidified and don't change that much.

Fully agree. It is not the language, but the functions around nixpkgs.

> Maybe that is difficult for people who haven't had an experience with pure/functional programming?

I found my understanding of the Nix language became a lot better once I started learning some Haskell. Specifically once I understood what currying was about.

My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough.

All builtins functions can how render doc with `:doc` in the `nix repl`. I think there's work to make this possible with any arbitrary function.

> My real gripe with Nix is the lack of a complete, easy to find, documentation of its "standard library". Nix Pills & a few wiki pages are far from enough.

How hard have you tried? It's literally two clicks and one scroll away from the official home page: https://nixos.org/ -> click "Learn" -> Scroll down -> click "Full Nix Manual":

https://nixos.org/manual/nix/stable/expressions/builtins.htm...

The other problem is the condescending replies from the higher tier nix folks while everyone else struggles. I almost think they garner a sadistic pleasure in watching everyone fail.

After months of "It's obviously this" and "you're not even trying" and "have you even looked?" and "there are plenty of examples out there already" and "you should start out by reading the introduction docs" and "you obviously don't know how functional languages work", I just stopped bothering.

I think the impedance mismatch is because some things are really simple, but are not documented in a way that is discoverable by someone who doesn't know, and is searching in the paradigm they do know.

I was trying to figure out how to install new machines from a central build host. Neither the straightforward install CD process, nor system.build.qcow2 made sense. I popped into the IRC channel to ask, and it turns out a 'nix build' 'nix copy', 'nix-env --store --set' and 'switch-to-configuration boot' did the trick. That's an extreme amount of power and simplicity that just kind of obviates a whole set of heavyweight processes (eg Debian automated-install). But if you are searching around for the usual type of automated install process, you just come up empty handed looking for it.

Maybe you should look within.

I'm still a long ways from understanding everything Nix/NixOS completely, but I've never gotten these kinds of comments apart from the extremely reasonable "you should start out by reading the introduction docs" - that the directions lead with.

And if you have a problem with that, I can see how you might have provoked that kind of response that seems so out of character to me.

I ask questions when I have them, and sometimes I get answers from them, and sometimes I answer them myself.

But I started off reading as much of the docs as I could tolerate before and while getting started, and always trying to self-help before asking for help.

This is a pretty good example the kind of victim blaming I'm talking about. It's a kind of insidious toxicity that permeates certain communities, although I've not been able to put my finger on what exactly brings it out, or why it's so tightly clung to as an acceptable behavior in some places.

I actually tried to help for awhile, and even started a help guide https://github.com/kstenerud/nixos-beginners-handbook/

But eventually one gets ground down and demoralized enough to just give up. It's a real shame, because I LOVE what NixOS is trying to accomplish.

I'm not trying to judge you harshly. I'm trying to understand.

In your first post in this thread, "high tier" NixOS users were called condescending sadists. This is a libel as far as I can tell based on my own experience.

Then was a list of disliked phrases, and second to last in that list was the instruction to read the manual. I believe in reading manuals, as difficult and time-consuming as the effort may be. This made me think expectations for using the project were wrong.

Now you're linking to a repo you made to attempt to give new users a guide to getting started.

You clearly made an effort to be part of the solution. This is admirable.

I'm trying to connect dots here - what I think happened was, in the course of trying to get help filling in the blanks, you probably exhausted the patience of others trying to help you.

I question if what you've been trying to do works at this point in the project's lifecycle. What you're trying to do is hard enough in a completely mature project. In an environment where we acknowledge the incompleteness of documentation, new command line APIs that are evolving, and new ways of doing things (I'm currently thinking of containers after looking at your guide, and flakes as well), communicating a true North is extremely difficult especially if you aren't one of the core developers immersed in the current state of change.

I don't think the project is mature enough to declare a "right way" to do all the things. I don't think we have enough mature users to support filling in all the blanks, yet, either.

I'm sorry you've had the experience you've had. Maybe after taking a break, you can resume your efforts, but with tempered expectations. We're all asking a lot of people who volunteer their time to build what should be acknowledged as a strategically important approach to computing.

We need more experts. The experts we do have are over-worked and under-appreciated. Perhaps you can help us there one day too.

Yes what you say absolutely all makes sense. My main gripe is that of culture, not substance.

It's understood and well communicated that the project is not mature enough to be an easy experience for a new user, and that's perfectly fair. But unfortunately, there's a degree of gatekeeperism going on in this community that is making the environment toxic for newcomers.

I've only seen it a few times before, but in every case, the longtimers seem unable to see it, and dismiss complaints by newcomers out of hand. Of course it's to be expected that a certain cohort of newcomers will be toxic and entitled, in which case one would absolutely be justified in dismissing them.

But that is not the case here, especially judging from the sheer number of upvotes my comments on this matter have received, and the number of blog posts in the wild about this very topic.

This is not a problem of maturity, but one of culture. And this is what exhausted me and made me give up on my attempt to make things better.

Right, it's unpleasant to see snark.

I hope my original comment doesn't read that way. I mean more "the Nix language isn't much different from something you're familiar with".

> "you should start out by reading the introduction docs"

This one I kinda buy, though.

With programming, with many things, you can get quite far without having to understand all the details. And many tools do quite well by being intuitive to use.

Nix is quite weird. And can be quite difficult. And it's got a small community, so it's under-documented and you won't always be able to find someone who's run into the same problem with a good explanation as to how to fix it.

This right here is enough for me to not even bother tying this OS. I'm always interested in operating systems (and the adjacent config systems that live on top of the Linux kernel, Arch Linux is one of those, Gentoo is another). But I'm not so interested in adding vitriol to my life, no matter the technical excellence. I'd rather live with a mundane kludge than deal with knowledge elitism.

In my experience the Nix community is extremely welcoming and refreshingly vitriol-free. This person isn't representative of the community.

>I'd rather live with a mundane kludge than deal with knowledge elitism.

But I would put up with a lot, if the payoff is more knowledge.

Lol cause one guy was cranky on the internet?

> The other problem is the condescending replies from the higher tier nix folks while everyone else struggles.

You may not like the reply, but the fact remains: the comment I replied to was a lie. It says there's hardly anything but Wiki pages and Nix Pills and that there's no "easy to find, documentation of its "standard library". And the exact document has been two clicks away from them for a long time.

> I just stopped bothering.

Another problem is your impatience and inability to perform searching and research for necessary information without anyone's help. The lack of focus and motivation to spend a little extra time to discover, learn, and build an intuition around a new toolchain is on you. How much time have you spent on useless media content on youtube or netflix lately instead having another try with the tool?

It’s obviously anecdotal but I’ve found the Nix community extremely supportive and haven’t really had that experience when asking questions. I typically stick to IRC but I have asked my fair share of dumb questions without any replies I’d call snarky…

Nix is wonderful, but absolutely is under-documented. (In part due to a small community, etc.).

A couple of examples I've run into:

https://github.com/NixOS/nix/issues/2259 showed people trying to make use of the "hello world" package which was given in the NixPkgs manual, but couldn't quite figure out how to get it to build.

e.g. if you want a package that's a simple script, "writeScriptBin" seems like what you'd want. -- But it's really not clear how to use it from the manual; you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri...

> you'd have to read the nixpkgs source. https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri...

Is it too much to ask from developers in 2022? At source, the function is well documented and is provided with an example [1]. The only missing part is a rendered HTML with the same information.

[1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...

It's one thing to look at the source, it's another thing to know that you have to look inside `pkgs/build-support/trivial-builders.nix` to find the documentation. One of the main advantages of reference documentation is a central place to look up what things do.

`writeScriptBin` is the second topmost link on Google search that leads directly to that file in a central repository of nixpkgs. Unique function names have the advantage of being transparent references that you can find either via google, or github search, or grep on your local checkout of nixpkgs.

In 2022, I think it's a reasonable expectation that API documentation can be accessed as rendered HTML. -- e.g. Haskell's or Rust's documentation even links to the source for the packages.

On the other hand, I think it's fair to say NixOS will sometimes require a high level of involvement from its users. When something goes wrong on another OS, it's easy to search for the answer. With NixOS, you have to understand both the Linux part, and the NixOS part.

> Is it too much to ask from developers in 2022?

In 2022 it's not too much to ask from the developers of the tools to provide:

- consistent and up-to-date documentation (that's built and updated together with the source code)

- consistent, readable and understandable error messages

> Is it too much to ask from developers in 2022?

It's not too much to ask for non-production ready software. If nixos is supposed to be production ready, then yes.

NixOS is production ready, productive teams that care about reproducibility use it in a variety of production environments already.

I was definitely in the "I just dont get it" camp for a couple years before coming across a comment on HackerNews pointing to Burke Libbeys fantastic playlist on Nix [1]. It was a revelation and was what I needed to finally have the DSL click for me. Cant recommend it enough.

[1] - https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...

Is there anything that explains the why and how a bit deeper?

As an example, in the video "Packaging a Gem as a Nix derivation", he basically just and copies and pastes another default.nix, changes some strings and mentions he doesn't understand what 'passthrough.updateScript' does, but just changes a string there too.

This doesn't really help me understand Nix.

I would watch the entire thing in order to get the "full experience" of his tutorial. This touches on things like the CLI vs just syntax.

If you are coming from the perspective of non-NixOS (e.g. HomeManager or just nixpkgs) then maybe start at his rundown of what NixOS is vs HomeManager [1].

Or if you really just want to understand the nix language itself then probably start at 'Demystifying nixpkgs' [2].

[1] - https://www.youtube.com/watch?v=IUsQt4NRCnc&list=PLRGI9KQ3_H...

[2] - https://www.youtube.com/watch?v=oWJaTb5uoT0&list=PLRGI9KQ3_H...

For me, nix the language itself is not that bad. It's all the magic happening in nixpkgs and the tight coupling there with the user interface (configuration.nix, shell.nix, etc.).

In NixOS/nix, you are essentially extending the nixpkgs source code with your own configuration to build a system, which requires good familiarity with the source. This would be like having to write C code to install packages on another OS. It's a questionable design choice but it does offer a lot of power.

> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions". Maybe that is difficult for people who haven't had an experience with pure/functional programming?

I've programmed professionally in Lisp (SBCL) and Clojure, and done a lot of hobby work in Haskell and Rust. I found Nix the language utterly incomprehensible largely because of documentation and tooling reasons.

I've programmed professionally in Haskell, I find Nix the Language to be one of the nicest DSLs for defining build pipelines. It's lazy, pure, and it's sandboxed. Whenever you need types on top of it you just pick Dhall and dhall-nix and continue with a productivity gain.

Wow, I just commented that dhall would probably be a fruitful language to consider for nix! And it seems to exist, though according to the readme, general recursion, not strongly typed code and row polymorphism is not supported by dhall but is used heavily by nix :/

Do you by chance know whether a non-Turing complete language like Dhall would be enough to “replace” nix?

> Do you by chance know whether a non-Turing complete language like Dhall would be enough to “replace” nix?

Realistically, I'd say Dhall should be viewed as a complimentary typed DSL for Nix instead "a replacement". Dhall shines when it's used as a code-generator for recursive Nix expressions from typed configs that capture the intent of a build pipeline. You can see how it can be generated from this Haskell example, for instance [1]. The [2] shows you the available constructs, that do support recursive calls and recursive Nix sets.

[1] https://hackage.haskell.org/package/dhall-nix-1.1.23/docs/Dh...

[2] https://hackage.haskell.org/package/hnix-0.14.0.2/docs/Nix-E...

The semantics are simple and necessary, yes. The syntax is kind of crap in some ways (in others it's awesome and I wish other languages were as lightweight). Syntax in general is a bikeshed, but that doesn't mean we can't objectively critique things like having function definition being a mere ":". That one on its own is probably responsible for much of the indecipherability.

Also some of the higher level constructs really aren't clear (like overrideDerivation/overrideAttrs/override, I still don't fully get). And mkDefault/mkForce/etc could be a bit more front and center rather than in "lib".

Also every time I run nixos-rebuild and it takes several+ seconds to evaluate my Nix expression I've got to wonder how much the implementation being this cute functional fixpoint is holding performance back.

> overrideDerivation/overrideAttrs/override, I still don't fully get

Packages are implemented as functions that take dependencies as arguments, do some stuff and ultimately output the result of calling mkDerivation (i.e. a derivation).

`override` allows you to change the arguments of the package, while `overrideAttrs` allows you to change the arguments of mkDerivation: the implementation of the package itself. `overrideDerivation` is essentially a deprecated `overrideAttrs` version.

https://nixos.org/manual/nixpkgs/stable/#chap-overrides for a better explenation.

Ah, I had forgotten `override` is easy. Rereading that page I still don't get the difference between `overrideAttrs` and `overrideDerivation`. `overrideAttrs` is newer and preferred, yet it doesn't spell out where you cannot use it and have to fall back to `overrideDeriviation`. And looking through my Nix code I've got various uses of `overrideDerivation`, which most likely means I tried `overrideAttrs` only to have it not work, so I tried the "deprecated" version and it did.

I think the manual is intetionally flying over `overrideDerivation` because it shouldn't be used. To understand the difference you'd have to know that `stdenv.mkDerivation` is a library function that wraps the Nix primitive `builtins.derivation`, which is what actually makes a derivation.

`overrideAttrs` changes the arguments of the former, while `overrideDerivation` changes the arguments of the latter. The reason is it's "deprecated" is that it forces a full evaluation of `stdenv.mkDerivation` before it can continue and it override the lower-level derivation, so some niceties that Nixpkgs provides don't work with it.

Thank you for explaining the difference! I think the manual would be better served by an explanation like that, rather than just implying that `overrideDerivation` may still need to be used for some unspecified reason. I'll have to revisit my uses and see why `overrideAttr` didn't work for me. Perhaps I was using the wrong argument name.

> the Nix language is about as straightforward as "JSON plus functions".

Except that they concoct weird custom terminology for everything.

It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight.

It's not a build script, it's a derivation.

Etc, etc.

> It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight.

This was intentional. Most hashing algorithms don't guarantee a stable ordering of keys. Nix was inspired by a research project called Aterm, which did have this property. Also, you can do things like reference other keys in an attr set, which many other dictionary data structures don't support.

> It's not a build script, it's a derivation.

Derivation encapsulates everything which goes into a building something. Dependencies, env vars, flags, sources, patches, the build script, package version, and package name all get packed into a derivation. These paramaters get hashed which is how the hash for the store path gets determined.

Derivations can be thought of an unambiguous build "recipe", which has already resolved based upon all configurable inputs (dependencies, build platform, host platform, target platform) .

https://book.divnix.com/ch04-01-create-a-derivation.html#ins...

Nix is optimized for creating reproducible builds.

> > It's not a hashmap, or a map, or an object. No. It's an attrset. Riiiiight.

> This was intentional. Most hashing algorithms don't guarantee a stable ordering of keys.

Then it's an ordered map.

Since you're creating a new language, you can say right up front "in Nix, all maps are ordered maps" and then just refer to them as maps.

There is existing terminology for all of this stuff, and it should have been reused.

Isn't a stable ordering just an n-tuple of pairs? Or is it more like a hashmap you access in O(1)?

> It's not a build script, it's a derivation.

Yes, because derivation's aren't build scripts. If you look in a .drv file (or better yet, pipe it through pretty-derivation), you'll see that derivations have a reference to a builder (i.e. the path to a binary), but derivations themselves aren't build scripts; they define the arguments and env vars for the builder (plus references to dependencies, output paths, and OS/architecture).

In practice, pretty much everything in Nixpkgs uses Bash as its builder; and almost all of those use the same 'default-builder.sh' script. However, Nix itself is independent of Nixpkgs, and we can give it any executable we like.

> It's not a build script, it's a derivation.

I think this one's a fair example of a specific terminology, though? The idea of building a package in a certain way, and storing it in a certain way, is foundational to the Nix packaging system.

Yeah, naming a key-value data structure `set` was a really poor choice. A derivation isn't really a build script though.

Fair enough, but prepending an adjective to "build script" would still have been a much better choice.

Like "elaborated build script". Or "transitively-hashed build script".

I think derivation as a new term of art is reasonable, because it's something that did previously not exist.

In particular it's not an "elaborate build script. The actual derivation is basically just a json file¹ with a path-name that's a function of its contents that includes specifying everything that goes into the build (env-var settings and arguments, the input sources, other required derivations, the build script, the standard environment -- all with transitively hashed paths) as well as what comes out of it.

They could maybe have called it build-spec, or something like that, but I think giving a novel thing a novel name is in fact novel is less confusing than trying to repurpose some existing terminology and trick people into thinking it's something they are already familiar with when actually it isn't.

¹ It's not actually json, but that's just some historical accident; `nix show-derivation ...` will actually output the derivation as pretty-printed json. But the key thing is that it's just simple data, not an executable script.

"elaborated", not "elaborate"

The former means "with all the details spelled out explicitly". The latter means "intricate".

And, I've yet to see a .drv file that contains absolutely 0% shell script. Let's be honest, nix is used mainly as a metaprogramming language for bash.

Seeing that the nix language was influenced heavily by haskell, perhaps Dhall would be an interesting “port”/change for the project - it is a deliberately non-Turing complete configuration language with types (but heavy type inference) and functions.

Because let’s be honest, types are user documentation as well, and the project would benefit greatly from the latter.

Can’t edit anymore but this more or less exists already: dhall-nix can convert from dhall to nix, but unfortunately not everything done in nixpkgs can be converted clearly into dhall (due to nixpkgs’s use of some non-strongly typed parts and general recursion)

We already had JSON plus functions. We called it 'JavaScript' :)

Ha, nice!

Seriously though, javascript is not a great language if you are looking for robust determinism. I can understand their decision to go elsewhere, given the domain and design.

People have tried: https://github.com/jkcfg/jk

But yeah I agree. The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts?

Google had the same problem for Bazel, and their solution (Starlark) is way easier to understand.

> The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts?

Yeah, that's a good point.

I don't see any reason determinism requires a functional paradigm. That said, the functional language communities probably value determinism more than the others, currently.

Choosing a language whose community values align with your needs can be a good thing.

JavaScript also includes bad footgun-features like procedures, aka functions with effects. Neither Nix nor JSON have this feature, making Nix in this aspect closer to JSON than JavaScript is.

> Maybe this is nitpicking, but: the Nix language is about as straightforward as "JSON plus functions".

It's too simple and straightforward. Writing Nix expressions is a bit like writing Javascript without frameworks or libraries.

Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.)

The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages.

I don't agree with this direction, though. Basic packages can already be described pretty simply using native nixlang, and the complexity scales well— you can add patches, fixups, flags on dependencies, extra fetcher args, whatever and it's a pretty smooth ramp all the way up. Whereas it would be considerably more jarring if you could use the "simple" thing up until the point where you abruptly hit a wall and then suddenly had to start over in real Nix when you hit that one thing that happens to require it.

Quite apart from that side of things, if a significant portion of nixpkgs were converted to the new simplified package definition style, it would majorly shrink the potential pool of example package definitions for novices to examine.

> The Nix community itself keeps talking about something similar as a first class citizen, like a YAML or TOML-type package definition scheme to be used for "simple" packages.

No, I'm talking about things like classes, abstract data types, modules, type checking and docstrings.

"Programming in the large".

Nixpkgs and NixOS does its own hand-rolled versions of these for each subproject. Eventually (a long time from now in a galaxy far away) we'll have some sort of standard Nix++ language and standard library.

Okay, yes, I agree with all of that. Flakes are kind of a module system, but having clearer semantics around functions and classes would definitely help with both code readability and producing better stack traces.

And a proper type system would be awesome.

Regarding docs, it is interesting that portions of the nixpkgs source do seem to have docblock-like comments above the functions, but AFAICT there's no formalized process for extracting or rendering those. Given that https://github.com/nix-community/rnix-parser exists, I wonder how big of a leap it would be to actually extract those, render them into rST pages, and generate a searchable Sphinx manual.

> Some sort of opinionated framework that compiles to Nix would be great for maintaining large Nix projects. (The Javascript world already went though this phase.)

Out of curiosity, are you talking about Typescript? Not really a framework, but I can't really think of a framework that 'won' in this sense for JS, and also compiles to JS.

On the front-end there's Svelte, which is actually compiled with Javascript, and React, which is has the biggest market share of opinionated Javascript frameworks, but at best you could say JSX is compiled to HTML.

On the back-end, there's express, but that doesn't involve any compilation, and is far from opinionated...

Before Typescript there was also Coffeescript. Sic transit. :)

But also things like Vue do their own compiling step too.

https://github.com/divnix/devos is something close to a framework.

I agree that language is too simple. Also I think some degree of IDE / language server support would help a lot. Refactoring modules, writing and importing custom functions was a bad experience for me - some arcane stacktraces were common, using repl was too verbose and with no clear way to debug whole configuration.

I just got a spare mini-PC up on DevOS over the weekend! It's currently looking for maintainers but it's cutting edge (think hlissner's NixOS config but more generic) and gives you a huge amount of flexibility out of the box. Highly recommended if you want a Flake-based NixOS system, local or remote but don't know where to start or you'd like an example of best practices to build off of.