4 ms·

I want to use nix it's the language that hurts for me. I keep trying to get into it, I have it on a mac laptop but Brew has gotten so good since I last used it

I want to use nix it's the language that hurts for me. I keep trying to get into it, I have it on a mac laptop but Brew has gotten so good since I last used it almost 4 years ago that I go back to that. Of course this is a whole env thing and not just a package thing but I dunno I'd almost rather build a container and work within that than write nix to get this functionality, the ergonomics of teh language are that galling for me.

ghthor 3y ago
I read this a lot and it prevented me from trying nix many years ago, instead I looked to guix and guile. Turns out, I don’t like schemes all that much. Started using nix this year, language is easy to use. Has very few concepts and syntax, it’s a standard functional language with all those goodies and a clean syntax in my opinion.
- __MatrixMan__ 3y ago
  I agree. I think the language gets blamed when it's a docs problem, and the docs get blamed because nix scratches the itch for so many different sorts of people. If you're a dev trying to replace poetry you're in a different world than a sysadmin trying to replace ansible, but documenting nix means addressing the needs of both parties. That's hard. The language is fine, especially compared with its alternatives (e.g. templated yaml, yuck).
Jhsto 3y ago
Devenv is often used with direnv, which just means that the environment is activated when you cd in to the folder. This is arguably a bit more than just a docker.
- gigatexal 3y ago
  that's actually kinda nice ...
llm_trw 3y ago
What gets me is the contradicting documentation. How are you meant to install a piece of software and keep it up to date? Is it a channel or flake? Are flakes stable or only for testing? So what's homemanager for? Good luck getting answers on those questions other than "read the source code" and then followed by "no, not that source code, this branch here". I really like the idea of Nix, but the communities priorities leave a lot to be desired of.
- Cyph0n 3y ago
  Regarding your questions, they seem to be about NixOS, which is a Linux distro that is centered around Nix. I usually recommend this guide for newcomers to Nix: https://zero-to-nix.com/ https://zero-to-nix.com/ I don’t think there’s a beginner-friendly guide to NixOS. I personally learned it (and continue to!) through a number of blog posts and examples on Github. The NixOS manual is a key reference to rely on, but not really a tutorial: https://nixos.org/manual/nixos/stable/ https://nixos.org/manual/nixos/stable/
- _kb 3y ago
  Flakes = combine explicit refs to deps as well as a build description for anything you're making (which can be a lib, app, or entire machine). IMO if you're starting now, use this. Channel = group of named deps. 'Traditional' nix tracks a channel so when you update it, anything pointed to it also updates. Home Manager = NixOS lite. Good option to define your preferred environment deterministically if you like another OS.
  - PurpleRamen 3y ago
    Was does "explicit ref" and "named dep" mean?
    - eska 3y ago
      A dependency at a particular version vs. the latest version of that dependency. The latter relies on a „channel“ snapshotting all available dependencies at a particular version. This is considered to be a mistake in hindsight, hence flakes
whateveracct 3y ago
Have you used the repl?
earthling8118 3y ago
The language is the easiest part. It's fairly simple, ergonomic, and actually pretty well made. Trying to use a container to accomplish the same thing is not a substitute. They are fundamentally different.
IshKebab 3y ago
I agree. Something that is emblematic of the problem: Nix has an implication operator. That's something that virtually no other language supports - it's normally something found in formal verification systems. The Nix language is designed by people that think everyone is familiar with lambda calculus and function programming. That's fine. But it's crazy to use a language like that for something that everyone has to use. I bet Nix would be way more popular if it used something like Starlark instead.
- gigatexal 3y ago
  yeah ... starlark being more imperitive kinda python-y would be really nice I'll keep trying to give Nix and the language more work on my end.
- colordrops 3y ago
  I guess. Been using Nix for two years and never knew it had an implication operator. It's mostly just json-like config with occasional code to do more complex things. You almost never have to use the heavier parts of the language unless you are developing Nix itself.
- fire_lake 3y ago
  Bazel would be so much better if it used Nix instead of Starlark (and had anonymous build targets).
  - IshKebab 3y ago
    Maybe if you already know Nix. But I'd prefer not to have to learn a new complicated (yeah despite what they say) language just for this.
- chriswarbo 3y ago
  > Something that is emblematic of the problem: Nix has an implication operator. That's something that virtually no other language supports - it's normally something found in formal verification systems. I wholeheartedly disagree. Nix's `a -> b` is just a boolean function, like `&&`, `||`, `==`, etc. It's meant for assertions, e.g. assert format == "csv" -> depth data == 2; Most languages allow assertions like this; they'd just be more awkward, like assert(depth(data) == 2 if format == "csv" else True) In fact, a common complaint about the Nix language is that it's untyped: which shows just how informal it is! > The Nix language is designed by people that think everyone is familiar with lambda calculus and function programming. That's fine. But it's crazy to use a language like that for something that everyone has to use. The Nix language is basically just "JSON with functions" (although the syntax is unfortunately different, since JSON wasn't so popular back around 2003; it does support XML though!). There's only an emphasis placed on functions since they're the USP of the language; otherwise we could just use plain JSON. Lambda calculus is just a simple model of functions; you don't need to know or care about it in order to write functions in the Nix language. In the same way that you can write integer arithmetic in Nix without knowing Peano's axioms, or von Neumann's set encoding of ordinals, or whatever. I've not used Starlark, but it seems to be waaaay more complicated than "JSON with functions"; e.g. it has loops, which makes the semantics dependent on some notion of time/temporal-ordering, which is sounds like a massive headache.
angra_mainyu 3y ago
Note: devenv.sh is a sane wrapper around nix. It's fairly straightforward to use. Running `devenv init` and then looking at the devenv.nix file should be all you need to know what to do. Package names can be found by `devenv search $name`.
chriswarbo 3y ago
> I'd almost rather build a container and work within that than write nix to get this functionality If you're happy writing shell commands/scripts, then just stick them in the following template: with import <nixpkgs> {}; runCommand "name-of-your-thing" { someEnvVar = "some value"; someOtherEnvVar = "some other value"; buildInputs = [ programs you want to run ]; # e.g. see search.nixos.org/packages } '' run any bash code you like here just make sure the file/folder you want to output uses the env var "$out" as its path ''
- gigatexal 3y ago
  Could these nix files just become yaml like docker files are? Seems a short stretch from functional to declarative no?
  - chriswarbo 3y ago
    You can always defunctionalise some particular code, to get a more static/declarative DSL. That's already quite a common pattern in Nix, where we can write Nix functions that act as interpreters for some more "declarative" DSL; indeed, many of the "foo2nix" utilities are just interpreters, written in Nix, for some third-party DSL; e.g. the "callCabal2nix" function in Nixpkgs can read the .cabal file of a Haskell project, and there are many other examples. The `builtins.readJSON` function is a particularly useful building block for such functions. I don't think it's a good idea to defunctionalise the Nix language itself, since the result would either be too inflexibile or incredibly complex. Keep in mind that the Nix language has no idea what a shell is, or any concept of "package", etc. yet it's flexible enough to write functions like `runCommand`, which is used in the example above. Also, it's reasonable to argue that Nix is already declarative, since that's what the `.drv` files are for! However, they're so tedious to work with that it's preferable to generate them using a "proper" language like the Nix expression language (or Guile Scheme if you're using Guix)! (See http://www.chriswarbo.net/projects/nixos/bottom_up.html http://www.chriswarbo.net/projects/nixos/bottom_up.html for a more in-depth explanation of .drv files, and how they relate to the Nix expression language)

ghthor 3y ago

I read this a lot and it prevented me from trying nix many years ago, instead I looked to guix and guile. Turns out, I don’t like schemes all that much. Started using nix this year, language is easy to use. Has very few concepts and syntax, it’s a standard functional language with all those goodies and a clean syntax in my opinion.

__MatrixMan__ 3y ago
I agree. I think the language gets blamed when it's a docs problem, and the docs get blamed because nix scratches the itch for so many different sorts of people. If you're a dev trying to replace poetry you're in a different world than a sysadmin trying to replace ansible, but documenting nix means addressing the needs of both parties. That's hard. The language is fine, especially compared with its alternatives (e.g. templated yaml, yuck).

Jhsto 3y ago

Devenv is often used with direnv, which just means that the environment is activated when you cd in to the folder. This is arguably a bit more than just a docker.

gigatexal 3y ago
that's actually kinda nice ...

llm_trw 3y ago

What gets me is the contradicting documentation. How are you meant to install a piece of software and keep it up to date? Is it a channel or flake? Are flakes stable or only for testing? So what's homemanager for? Good luck getting answers on those questions other than "read the source code" and then followed by "no, not that source code, this branch here". I really like the idea of Nix, but the communities priorities leave a lot to be desired of.

Cyph0n 3y ago
Regarding your questions, they seem to be about NixOS, which is a Linux distro that is centered around Nix. I usually recommend this guide for newcomers to Nix: https://zero-to-nix.com/ https://zero-to-nix.com/ I don’t think there’s a beginner-friendly guide to NixOS. I personally learned it (and continue to!) through a number of blog posts and examples on Github. The NixOS manual is a key reference to rely on, but not really a tutorial: https://nixos.org/manual/nixos/stable/ https://nixos.org/manual/nixos/stable/
_kb 3y ago
Flakes = combine explicit refs to deps as well as a build description for anything you're making (which can be a lib, app, or entire machine). IMO if you're starting now, use this. Channel = group of named deps. 'Traditional' nix tracks a channel so when you update it, anything pointed to it also updates. Home Manager = NixOS lite. Good option to define your preferred environment deterministically if you like another OS.
- PurpleRamen 3y ago
  Was does "explicit ref" and "named dep" mean?
  - eska 3y ago
    A dependency at a particular version vs. the latest version of that dependency. The latter relies on a „channel“ snapshotting all available dependencies at a particular version. This is considered to be a mistake in hindsight, hence flakes

whateveracct 3y ago

Have you used the repl?

earthling8118 3y ago

The language is the easiest part. It's fairly simple, ergonomic, and actually pretty well made. Trying to use a container to accomplish the same thing is not a substitute. They are fundamentally different.

IshKebab 3y ago

I agree. Something that is emblematic of the problem: Nix has an implication operator. That's something that virtually no other language supports - it's normally something found in formal verification systems. The Nix language is designed by people that think everyone is familiar with lambda calculus and function programming. That's fine. But it's crazy to use a language like that for something that everyone has to use. I bet Nix would be way more popular if it used something like Starlark instead.

gigatexal 3y ago
yeah ... starlark being more imperitive kinda python-y would be really nice I'll keep trying to give Nix and the language more work on my end.
colordrops 3y ago
I guess. Been using Nix for two years and never knew it had an implication operator. It's mostly just json-like config with occasional code to do more complex things. You almost never have to use the heavier parts of the language unless you are developing Nix itself.
fire_lake 3y ago
Bazel would be so much better if it used Nix instead of Starlark (and had anonymous build targets).
- IshKebab 3y ago
  Maybe if you already know Nix. But I'd prefer not to have to learn a new complicated (yeah despite what they say) language just for this.
chriswarbo 3y ago
> Something that is emblematic of the problem: Nix has an implication operator. That's something that virtually no other language supports - it's normally something found in formal verification systems. I wholeheartedly disagree. Nix's `a -> b` is just a boolean function, like `&&`, `||`, `==`, etc. It's meant for assertions, e.g. assert format == "csv" -> depth data == 2; Most languages allow assertions like this; they'd just be more awkward, like assert(depth(data) == 2 if format == "csv" else True) In fact, a common complaint about the Nix language is that it's untyped: which shows just how informal it is! > The Nix language is designed by people that think everyone is familiar with lambda calculus and function programming. That's fine. But it's crazy to use a language like that for something that everyone has to use. The Nix language is basically just "JSON with functions" (although the syntax is unfortunately different, since JSON wasn't so popular back around 2003; it does support XML though!). There's only an emphasis placed on functions since they're the USP of the language; otherwise we could just use plain JSON. Lambda calculus is just a simple model of functions; you don't need to know or care about it in order to write functions in the Nix language. In the same way that you can write integer arithmetic in Nix without knowing Peano's axioms, or von Neumann's set encoding of ordinals, or whatever. I've not used Starlark, but it seems to be waaaay more complicated than "JSON with functions"; e.g. it has loops, which makes the semantics dependent on some notion of time/temporal-ordering, which is sounds like a massive headache.

angra_mainyu 3y ago

Note: devenv.sh is a sane wrapper around nix. It's fairly straightforward to use. Running `devenv init` and then looking at the devenv.nix file should be all you need to know what to do. Package names can be found by `devenv search $name`.

chriswarbo 3y ago

> I'd almost rather build a container and work within that than write nix to get this functionality If you're happy writing shell commands/scripts, then just stick them in the following template: with import <nixpkgs> {}; runCommand "name-of-your-thing" { someEnvVar = "some value"; someOtherEnvVar = "some other value"; buildInputs = [ programs you want to run ]; # e.g. see search.nixos.org/packages } '' run any bash code you like here just make sure the file/folder you want to output uses the env var "$out" as its path ''

gigatexal 3y ago
Could these nix files just become yaml like docker files are? Seems a short stretch from functional to declarative no?
- chriswarbo 3y ago
  You can always defunctionalise some particular code, to get a more static/declarative DSL. That's already quite a common pattern in Nix, where we can write Nix functions that act as interpreters for some more "declarative" DSL; indeed, many of the "foo2nix" utilities are just interpreters, written in Nix, for some third-party DSL; e.g. the "callCabal2nix" function in Nixpkgs can read the .cabal file of a Haskell project, and there are many other examples. The `builtins.readJSON` function is a particularly useful building block for such functions. I don't think it's a good idea to defunctionalise the Nix language itself, since the result would either be too inflexibile or incredibly complex. Keep in mind that the Nix language has no idea what a shell is, or any concept of "package", etc. yet it's flexible enough to write functions like `runCommand`, which is used in the example above. Also, it's reasonable to argue that Nix is already declarative, since that's what the `.drv` files are for! However, they're so tedious to work with that it's preferable to generate them using a "proper" language like the Nix expression language (or Guile Scheme if you're using Guix)! (See http://www.chriswarbo.net/projects/nixos/bottom_up.html http://www.chriswarbo.net/projects/nixos/bottom_up.html for a more in-depth explanation of .drv files, and how they relate to the Nix expression language)