7 ms·

Have there been any good efforts into getting rid of the language or providing an alternative? My effort into switching and the biggest complaint I've read is t

Have there been any good efforts into getting rid of the language or providing an alternative? My effort into switching and the biggest complaint I've read is that the idea behind NixOS and the ecosystem is genius but one of the biggest draw backs is writing everything in Nix. I spend a weekend every so often defining the core of what I want next time I upgrade, but just find it so annoying I'm sure I won't use anything I've written until there's a major change in the ecosystem.

maxloh 2y ago
It seems to be an issue with testing and debugging, rather than the language itself. The same issue would also be present if you could switch to any other language for configuration.
kjuulh 2y ago
Nickel lang is such an effort. Id say the syntax is a mix of json and lua and aims for a non-touring complete program. It is still a bit early but it looks promising
- pxc 2y ago
  No, Nickel is Turing-complete. That's been one of the characteristics intended to distinguish it from most other configuration languages from the start. See the 'RATIONALE' document: https://github.com/tweag/nickel/blob/378ece30b3e3c0ab488f65956ca509345ba62900/RATIONALE.md#turing-completeness https://github.com/tweag/nickel/blob/378ece30b3e3c0ab488f659...
turboponyy 2y ago
What's so bad about it? Putting aside the poor typing (the lack of proper typing is a shame, so valid criticism), I actually really like the language - it's genuinely a great DSL for the particular problems it's supposed to handle. It does take a bit of use for it to click, though. A lot of it has to do not with Nixlang itself but about learning nixpkgs' idioms.
- k_bx 2y ago
  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.
  - hamandcheese 2y ago
    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 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.
    - lloeki 2y ago
      > 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.
  - arianvanp 2y ago
    There is this: https://github.com/nix-community/nixd 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
  - rendaw 2y ago
    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).
adrian_b 2y ago
There is Guix, which replaces the Nix language with Scheme, but which has some limitations related to a smaller user base, e.g. a smaller package collection. Replacing the language requires duplicating all the work that went into Nix, to reach parity, so it is not easy.
- duped 2y ago
  > Replacing the language requires duplicating all the work that went into Nix, to reach parity, so it is not easy. That seems like a design flaw in Nix, there's no reason the data model should be so tightly coupled to the scripting implementation that you can't reuse packages written in a different language.
  - hamandcheese 2y ago
    There is no technical barrier against doing that. But much of the power and flexibility in nixpkgs arises from the nix language, not the data model (which is comparatively simple). For example, see zb: https://www.zombiezen.com/blog/2024/09/zb-early-stage-build-system/ https://www.zombiezen.com/blog/2024/09/zb-early-stage-build-... Using a different language to depend on packages derived from .nix would be very much akin to depending on a docker image whose Dockerfile you can not inspect.
    - rollcat 2y ago
      > Using a different language to depend on packages derived from .nix would be very much akin to depending on a docker image whose Dockerfile you can not inspect. Speaking of Docker images and Dockerfiles, that's actually a real-world example of how you can achieve this kind of effect without relying on a specific language. Ironically, you can use Nix to build Docker images; there's a bunch of other alternative builders (e.g. Kaniko, Buildah); you can also just stitch together some files&metadata into tarballs, and then 'docker import' it. Nix or Guix are of course much more powerful and expressive than Docker images, but there's always a cost to complexity.
    - duped 2y ago
School-Cotton 2y ago
> Have there been any good efforts into getting rid of the language or providing an alternative? Guix is conceptually similar to Nix but uses scheme.
tkz1312 2y ago
I find the nix language to be quite pleasant. There are some syntax quirks and types would be nice, but in general the “json with functions” vibe is imo great and a very nice fit for the domain. Lots of other modern config languages (e.g. dhall, jsonnet) have ended up in this part of the design space too. With that said tweag has been working on a kind of nix 2.0 / nix with types for a while with the aim (I think) of being able to use it in nixpkgs: https://github.com/tweag/nickel https://github.com/tweag/nickel
- the_duke 2y ago
  I also quite like nixlang for config tasks - in theory! In practice its really annoying. I think the main problem is the interpreter and the bad error messages / bad debuggability. Part of that just comes from lazy evaluation, which makes debugging a lot harder in general (you feel this in Haskell...), but also just from nix not being a big popular language that gets lots of polish, and being completely dynamically typed.
- poincaredisk 2y ago
  Nix is ok. I like jsonnet more, and once I've tried to write a converter from jsonnet to nix, but it turned out this is much harder than expected (some idioms don't transfer from nix to jsonnet well.
- anon291 2y ago
  Me as well. As a haskell / ML programmer, it is extremely intuitive. It's non-innovative (In a good way). Literally it's just a functional scripting language.
seanhunter 2y ago
I don't think the language is the issue here[1]. It seems inevitable to me that some of the design choices around immutability and isolation are going to result in a larger server image (both on disk and in memory) than if you are prepared to forgo those things. For most people that tradeoff is probably worth it but if you want something to run in an embedded server or with a very low disk footprint it's probably not right for you. Around 20 years ago people who wanted to do this[2] used to make tiny immutable redhat servers by remounting /usr and a few other things read-only after boot so it's certainly doable but it's a lot more of a pain than what nix does and there is no process isolation and no rollback etc when things go wrong. [1] ...or generally in fact but that's a matter of opinion and I know people feel differently about this. [2] me for one, but others also.
SuperSandro2000 2y ago
What do you want to replace it with? YAML? The language won't go away and you should try to look at it for more than I don't like it.
frankjr 2y ago
The Nix language also doesn't need to exist. They want to write pure lazy declarative derivations - great, you can do that in any existing language. It's a matter of style and APIs. You don't need to spend years developing a brand new language from scratch. Not to mention that many derivations end up calling a Bash script underneath anyway because at some point you actually need to perform an action in the real world. How would a derivation looked like if written in <insert your favorite scripting language> with lazy APIs?
- weatherlight 2y ago
  That's not true. The language needs to be declarative. if you use your favorite lang and develop a DSL around those APIS, that DSL would be declarative.. also the language itself, isn't that complicated.... it's really quite minimal. It has its roots in ML. I honestly think people expect everything to look like javascript or C++ and it's a shame honestly.
  - jen20 2y ago
    Pulumi is a great example of declarative APIs built with imperative programming languages. SwiftUI is another. Personally I have nothing against the Nix language, and use it without issue, but it's untrue to suggest that the language itself requires uncommon support for this kind of thing.
    - fsociety 2y ago
      Some people don't want to hear this, but it is 100% true.
    - hiatus 2y ago
      Personally I see it as similar to typed vs untyped languages. You can add typing to untyped languages or you can just use a typed language. The language used shapes the structure and some are easier to reason about than others (to some people).
    - anon291 2y ago
otabdeveloper4 2y ago
No, writing this in any other language will definitely make for a much shittier Nix experience. The problem isn't the language, the problem is that nixpkgs (and NixOS) are just huge.
Nathanba 2y ago
yes, https://github.com/garnix-io/garn https://github.com/garnix-io/garn But weirdly there was little interest and they rebranded themselves around being a more general build system based on nix instead of what they originally said about being a nix reimplmentation in typescript.

maxloh 2y ago

It seems to be an issue with testing and debugging, rather than the language itself. The same issue would also be present if you could switch to any other language for configuration.

kjuulh 2y ago

Nickel lang is such an effort. Id say the syntax is a mix of json and lua and aims for a non-touring complete program. It is still a bit early but it looks promising

pxc 2y ago
No, Nickel is Turing-complete. That's been one of the characteristics intended to distinguish it from most other configuration languages from the start. See the 'RATIONALE' document: https://github.com/tweag/nickel/blob/378ece30b3e3c0ab488f65956ca509345ba62900/RATIONALE.md#turing-completeness https://github.com/tweag/nickel/blob/378ece30b3e3c0ab488f659...

turboponyy 2y ago

What's so bad about it? Putting aside the poor typing (the lack of proper typing is a shame, so valid criticism), I actually really like the language - it's genuinely a great DSL for the particular problems it's supposed to handle. It does take a bit of use for it to click, though. A lot of it has to do not with Nixlang itself but about learning nixpkgs' idioms.

k_bx 2y ago
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.
- hamandcheese 2y ago
  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 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.
  - lloeki 2y ago
    > 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.
- arianvanp 2y ago
  There is this: https://github.com/nix-community/nixd 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
- rendaw 2y ago
  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).

adrian_b 2y ago

There is Guix, which replaces the Nix language with Scheme, but which has some limitations related to a smaller user base, e.g. a smaller package collection. Replacing the language requires duplicating all the work that went into Nix, to reach parity, so it is not easy.

duped 2y ago
> Replacing the language requires duplicating all the work that went into Nix, to reach parity, so it is not easy. That seems like a design flaw in Nix, there's no reason the data model should be so tightly coupled to the scripting implementation that you can't reuse packages written in a different language.
- hamandcheese 2y ago
  There is no technical barrier against doing that. But much of the power and flexibility in nixpkgs arises from the nix language, not the data model (which is comparatively simple). For example, see zb: https://www.zombiezen.com/blog/2024/09/zb-early-stage-build-system/ https://www.zombiezen.com/blog/2024/09/zb-early-stage-build-... Using a different language to depend on packages derived from .nix would be very much akin to depending on a docker image whose Dockerfile you can not inspect.
  - rollcat 2y ago
    > Using a different language to depend on packages derived from .nix would be very much akin to depending on a docker image whose Dockerfile you can not inspect. Speaking of Docker images and Dockerfiles, that's actually a real-world example of how you can achieve this kind of effect without relying on a specific language. Ironically, you can use Nix to build Docker images; there's a bunch of other alternative builders (e.g. Kaniko, Buildah); you can also just stitch together some files&metadata into tarballs, and then 'docker import' it. Nix or Guix are of course much more powerful and expressive than Docker images, but there's always a cost to complexity.
  - duped 2y ago

School-Cotton 2y ago

> Have there been any good efforts into getting rid of the language or providing an alternative? Guix is conceptually similar to Nix but uses scheme.

tkz1312 2y ago

I find the nix language to be quite pleasant. There are some syntax quirks and types would be nice, but in general the “json with functions” vibe is imo great and a very nice fit for the domain. Lots of other modern config languages (e.g. dhall, jsonnet) have ended up in this part of the design space too. With that said tweag has been working on a kind of nix 2.0 / nix with types for a while with the aim (I think) of being able to use it in nixpkgs: https://github.com/tweag/nickel https://github.com/tweag/nickel

the_duke 2y ago
I also quite like nixlang for config tasks - in theory! In practice its really annoying. I think the main problem is the interpreter and the bad error messages / bad debuggability. Part of that just comes from lazy evaluation, which makes debugging a lot harder in general (you feel this in Haskell...), but also just from nix not being a big popular language that gets lots of polish, and being completely dynamically typed.
poincaredisk 2y ago
Nix is ok. I like jsonnet more, and once I've tried to write a converter from jsonnet to nix, but it turned out this is much harder than expected (some idioms don't transfer from nix to jsonnet well.
anon291 2y ago
Me as well. As a haskell / ML programmer, it is extremely intuitive. It's non-innovative (In a good way). Literally it's just a functional scripting language.

seanhunter 2y ago

I don't think the language is the issue here[1]. It seems inevitable to me that some of the design choices around immutability and isolation are going to result in a larger server image (both on disk and in memory) than if you are prepared to forgo those things. For most people that tradeoff is probably worth it but if you want something to run in an embedded server or with a very low disk footprint it's probably not right for you. Around 20 years ago people who wanted to do this[2] used to make tiny immutable redhat servers by remounting /usr and a few other things read-only after boot so it's certainly doable but it's a lot more of a pain than what nix does and there is no process isolation and no rollback etc when things go wrong. [1] ...or generally in fact but that's a matter of opinion and I know people feel differently about this. [2] me for one, but others also.

SuperSandro2000 2y ago

What do you want to replace it with? YAML? The language won't go away and you should try to look at it for more than I don't like it.

frankjr 2y ago

The Nix language also doesn't need to exist. They want to write pure lazy declarative derivations - great, you can do that in any existing language. It's a matter of style and APIs. You don't need to spend years developing a brand new language from scratch. Not to mention that many derivations end up calling a Bash script underneath anyway because at some point you actually need to perform an action in the real world. How would a derivation looked like if written in <insert your favorite scripting language> with lazy APIs?

weatherlight 2y ago
That's not true. The language needs to be declarative. if you use your favorite lang and develop a DSL around those APIS, that DSL would be declarative.. also the language itself, isn't that complicated.... it's really quite minimal. It has its roots in ML. I honestly think people expect everything to look like javascript or C++ and it's a shame honestly.
- jen20 2y ago
  Pulumi is a great example of declarative APIs built with imperative programming languages. SwiftUI is another. Personally I have nothing against the Nix language, and use it without issue, but it's untrue to suggest that the language itself requires uncommon support for this kind of thing.
  - fsociety 2y ago
    Some people don't want to hear this, but it is 100% true.
  - hiatus 2y ago
    Personally I see it as similar to typed vs untyped languages. You can add typing to untyped languages or you can just use a typed language. The language used shapes the structure and some are easier to reason about than others (to some people).
  - anon291 2y ago

otabdeveloper4 2y ago

No, writing this in any other language will definitely make for a much shittier Nix experience. The problem isn't the language, the problem is that nixpkgs (and NixOS) are just huge.

Nathanba 2y ago

yes, https://github.com/garnix-io/garn https://github.com/garnix-io/garn But weirdly there was little interest and they rebranded themselves around being a more general build system based on nix instead of what they originally said about being a nix reimplmentation in typescript.