It's not just poor typing. It's the lack of discoverability. "What are all my options here in this expression? What are the symbols available?"

I think a good IDE integration could solve this, but not sure how much is possible.

The nix repl can be a very valuable tool in answering these questions.

That said, I strive to structure my nix source so that portions of it can easily be pasted into a repl. ReadTree goes a long way in that regard: https://github.com/tvlfyi/kit/tree/canon/readTree

More to your point, though: I think a lot is possible. Although nix is very dynamic, it is also, for all intents and purposes, side effect free. I've had this idea that a sufficiently advanced IDE should be able to evaluate your nix code and tell you exactly what the possible values (not just types, but value!) are for any particular variable.

> I've had this idea that a sufficiently advanced IDE should be able to evaluate your nix code and tell you exactly what the possible values (not just types, but value!)

Similarly to the REPL, I'm often using `nix-instantiate --eval -E 'somethingsomething'` so it should definitely be possible.

There is this: https://github.com/nix-community/nixd

It has jump to definition and autocomplete. Which is very nice.

It's not perfect. But it's pretty good

Like (iirc) systemd-resolved has `enabled` which is false by default but then gets silently turned on if you use systemd-networkd. How are you supposed to figure that out without reading the source?

But I think this also stems from the fact that the default state of nixos is "a general purpose linux system" and so instead of just starting at 0 and adding the things you need, you have to mix adding and removing things which IMO makes things much more complicated (except maybe for newbies to linux who don't know what's necessary for a running system).

For other distros, that kind of behind the scenes changes are triggered by package installation and ad-hoc commands. It's not always easy to figure out exactly what has changed, especially after the fact. This, in turn, makes changes difficult to revert.

NixOS is much better because you can inspect the changes after the fact. You also know which code to look for, which is a luxury. If the code seems too much, there's the repl to help. Changes are also much easier to revert.

nixos-rebuild repl and then you can inspect things like config.services.resolved.enable or :p options.services.resolved.enable.definitionsWithLocations

With a default config you start with a console, systemd, dbus and some things to make it boot. There is barely anything.

You instantiate the nix config and then lookup the value

`nix-instantiate --eval -A config.services.resolved.enabled /etc/nixos/configuration.nix`

This is way better than a stateful package manager making a non-revertible change without even telling me.

This is inherently a Hard Problem™, since completions may require evaluating arbitrary derivations (e.g. building a custom Linux kernel).

For "what symbols are available", the nil LSP implementation[1] works for anything in scope that doesn't require evaluation. It also includes completions for the stdlib and NixOS options (in certain contexts).

Another LSP implementation is nixd[2], which is trying to tackle the problem of evaluations for completion.

[1] https://github.com/oxalica/nil/

[2] https://github.com/nix-community/nixd

Maybe then IDE is not the best target, but rather a clear "REPL-friendliness at all times" is, e.g. everything is built around constant re-evaluation where you can discover things where interested, maybe put stop gaps and prints easily.

There is https://search.nixos.org/ and on the command line you can play around with:

$ nix repl

nix-repl> :l <nixpkgs>

nix-repl> {press tab for auto-complete}

But that’s not the fault of the language. insert another DSL would have the same issues.

> What are all my options here in this expression? What are the symbols available?"

Unlike most languages, the symbols available are completely determined by the scope. Just look at the let expressions in effect. There's no magic.

As for nested expressions, that's a typing problem, which was already mentioned above as a pain point (although there are several efforts to fix this).

The community has built two LSPs, and https://search.nixos.org/options (or "man configuration.nix", if you prefer) shows what NixOS options are available

Way too much sugar/"idioms", which makes it hard for someone new to the language to figure out what a given piece of code is actually doing. Confusing use of semicolons for what almost every other language uses commas or newlines (or nothing) for. It's the same feeling as writing bash, and needing to always look up again exactly what the syntax is and where the semicolons go.

Here's all the cases for using a semicolon. (estimated 30 seconds read)

1. At the end of local variables

   let
     a = 1;
     b = 2;
    in
    a + b

    result: 3

2. At the end of each attributes in an attribute set (a.k.a. dictionaries or key-value pairs)

    {
      a = 1;
      b = 2;
    }

    result: { a = 1; b = 2; }

3. with expressions

    with pkgs;

    coreutils

    result: (the coreutils attribute in the pkgs attribute set)

4. Assertions

    assert a != null;

    a

    result: (the value of a)

Now, you'll never be confused again.

This sounds like a skill problem if you don't even know bash or rust or PHP syntax.