It’s okay but still not very thorough. I would’ve expected it to show code comparison: they show some complex Dhall code but no corresponding Nickel code.
No types is a major pain; I spend so much time grepping around nixpkgs for stuff because I have no idea what form an argument takes, so I have to find the call site, figure out what value was passed in, and that value is usually the result of some other function call, so I need to find that function definition and figure out what value it returns, which is itself the result of some function call, and so on until the heatdeath of the universe all to answer a question that should be easily answered by hovering my cursor over the original variable. :)
Relatedly, the nix folks don’t seem to like documentation or informative variable names, but that’s not strictly a language problem.
It’s all part of the ecosystem of the language. A proper language server would probably also be able to track down any value through all the files and show it.
I have yet to understand what it is Flakes are exactly, even after reading about it multiple times over some time. Can you explain what it is Flakes provide you?
Sure I would like to figure that out too. Lets say I have a project and I want development shell that bring in all the dependency to build the project AND those dependencies are not in guix’s tree, they are in independent channels.
dev shell
In guix I think you would make a channels.scm and do guix time-machine -C channels.scm something? to enter your development shell?
In nix you specify what packages you want in your dev shell and the other flakes which are dependencies in flakes.nix as inputs. To enter the dev shell nix develop
updating
To update your project’s dependencies in nix you do
nix flake update
guix is guix pull --channels=./my-channels.scm and guix describe --format=channels > ./channels.scm
(im not 100% those are equivalent).
distribution
If I want distribute whatever I was working on in nix I just need to add package output to my flake.nix. Then other’s can include my flake in there flake.
In guix I have to create an channel which also references the other channels that my project depend on. Do the channels that where pinned in ‘./channels.scm’ stay pinned when other people use my channel?
How does guix deal with conflicting package between channels? In nix dependent flakes are arguments to a function (example) and you have to manually join the package sets, or just reference the argument variable.
Overall all my impression is that flakes are more composable then guix channels. And I think this composablity is important. I don’t want a giant repository of packages, I would just rather have one channel or flake per package. In nix that is easy to do and I would love to know how to do it in guix. I like scheme and guix’s bootstrap story a lot.
Seems correct, guix time-machine -C channels.scm -- shell hello will get you a development environment with the package hello in it as specified by the channel version specified in channel.scm. It seems like you could combine this with inferior guixes to pull packages out of arbitrary revisions of channels, but that API is not stable yet.
But thank you for your explanation of flakes. They seems to be Russian nesting dolls of packages from specific channel version. I’m on foot now but if I remember I will ask around in IRC when I get to a real computer if its possible to compose channel files like flakes.
About conflicts: In Scheme code you can adress them uniquely through their inferior parentes (what an amazing sentance btw). In the produced shell environment the latest specified package takes precedence.
I don’t have any interest in an OS (also doing my best to ignore NixOS as much as possible). The scheme based go at the same thing is interesting but Nix is already borderline too niche for me.
Nix on MacOS is a relatively common and discussed usage of Nix.
Yeah, it’s just that you have to wade through half the comms being about NixOS.
I talked to a colleague where they had Nix adopted in a part of a large company and every time somebody mentioned it, first they had to create clarity what it was that the person was talking about (language, packages, OS or something else entirely).
I was using HCL to configure my service but it was getting in the way as well as being a fairly large dependency and I never quite got it right (eg my configs never worked the same way as say Hashicorp’s do, I am sure I didn’t grok something very well).
I recently refactored a bunch of the data model and switched to plain unmarshalled json for configuration. It’s a lot more verbose of course but directly maps to the data structures being configured and is much clearer than the half baked DSL I was trying to define using hcl.
For the verboseness I have grand plans to produce a library/schema[fixtypo] in Nickel to generate the json for my configuration that should tame that somewhat and it will (obviously) become an optional external dependency instead of compile time.
JSON5 was started in 2012, and as of 2022, now gets >65M downloads/week, ranks in the top 0.1% of the most depended-upon packages on npm, and has been adopted by major projects like Chromium, Next.js, Babel, Retool, WebStorm, and more. It’s also natively supported on Apple platforms like MacOS and iOS.
I thought the same thing when first visiting on mobile. On desktop there is an interactive example. I’m not sure why it doesn’t show on mobile, but ideally there would be a static fallback code sample for mobile.
I’d love to see documentation on embedding, and some implementations in other languages (Go would be useful to me) would be nice. Otherwise, it’s hard for tools to use Nickel as their preferred config language.
Generally looks good and in the ML frame with let rec … in. I like that JSON, YAML, & TOML are all supported out of the box until there could be a greater adoption. The burden of all the type info aside, I would miss Dhall’s syntax (and Unicode!) though. Relatedly, I wonder why they went with => over -> or → for functions–last language I recall doing that was ReasonML. Is it because these arrows are reserved only for type-level annotation? The only real issues I have with Dhall is the only good parser/interpreter is in Haskell so unless you’re writing Haskell or just planning to run like dhall-to-json to generate a file or the simplest Bash script, it basically can’t be used (like transferring typed data within your own project, holding onto that typed information). Because of this, I think Nickel could have more immediate usability. I haven’t looked at it in ages, but now I wanna give it a go.
Please name your mascot Nickelangelo.
Their repo has a page that answered several of the questions I had (e.g. how does this compare to Dhall).
It’s okay but still not very thorough. I would’ve expected it to show code comparison: they show some complex Dhall code but no corresponding Nickel code.
No mention of it being a successor to Nix-the-language. Is that off the table?
Nope it seems not: https://discourse.nixos.org/t/nickel-1-0-release/28252 and from there to https://github.com/nickel-lang/nickel-nix
Given how things progress, that is going to be… a process.
Still I look forward to it even though Nickel is quite esoteric, it does not make my eyes bleed like Nixlang does.
How does Nix make your eyes bleed?
inherit
,with
, etc.).Like, it does the/a job but it’s never going to win any prize for beauty or elegance.
No types is a major pain; I spend so much time grepping around nixpkgs for stuff because I have no idea what form an argument takes, so I have to find the call site, figure out what value was passed in, and that value is usually the result of some other function call, so I need to find that function definition and figure out what value it returns, which is itself the result of some function call, and so on until the heatdeath of the universe all to answer a question that should be easily answered by hovering my cursor over the original variable. :)
Relatedly, the nix folks don’t seem to like documentation or informative variable names, but that’s not strictly a language problem.
I just found a band-aid, the nil language server is a big help.
It displays lots of helpful information. I can’t find a screenshot, but it’s worth trying.
Oh, cool. Thanks for the tip. If I’m ever brave enough to venture back into Nix again, I will have to check this out! :)
It’s all part of the ecosystem of the language. A proper language server would probably also be able to track down any value through all the files and show it.
Have you tried Guix? (Shameless plug of my favorite config lang.)
guile is nice to work with but nix has flakes
I have yet to understand what it is Flakes are exactly, even after reading about it multiple times over some time. Can you explain what it is Flakes provide you?
Reading the following post it seems you could achieve the same effect with
guix time-machine
and some flags: https://lists.gnu.org/archive/html/guix-devel/2023-03/msg00022.htmlI haven’t found anything better than this, which seems somewhat outdated: https://serokell.io/blog/practical-nix-flakes
I’m working on adding flakes coverage to nix-shorts.
Sure I would like to figure that out too. Lets say I have a project and I want development shell that bring in all the dependency to build the project AND those dependencies are not in guix’s tree, they are in independent channels.
dev shellguix time-machine -C channels.scm something?
to enter your development shell?flakes.nix
asinputs
. To enter the dev shellnix develop
To update your project’s dependencies in nix you do
nix flake update
guix pull --channels=./my-channels.scm
andguix describe --format=channels > ./channels.scm
(im not 100% those are equivalent).How does guix deal with conflicting package between channels? In nix dependent flakes are arguments to a function (example) and you have to manually join the package sets, or just reference the argument variable.
Overall all my impression is that flakes are more composable then guix channels. And I think this composablity is important. I don’t want a giant repository of packages, I would just rather have one channel or flake per package. In nix that is easy to do and I would love to know how to do it in guix. I like scheme and guix’s bootstrap story a lot.
Seems correct,
guix time-machine -C channels.scm -- shell hello
will get you a development environment with the package hello in it as specified by the channel version specified in channel.scm. It seems like you could combine this with inferior guixes to pull packages out of arbitrary revisions of channels, but that API is not stable yet.But thank you for your explanation of flakes. They seems to be Russian nesting dolls of packages from specific channel version. I’m on foot now but if I remember I will ask around in IRC when I get to a real computer if its possible to compose channel files like flakes.
About conflicts: In Scheme code you can adress them uniquely through their inferior parentes (what an amazing sentance btw). In the produced shell environment the latest specified package takes precedence.
Nix flakes are derivations that build a reproducible output based on some input, all the inputs are hashed, tracked by git revision etc.
I don’t have any interest in an OS (also doing my best to ignore NixOS as much as possible). The scheme based go at the same thing is interesting but Nix is already borderline too niche for me.
Neither Nix nor Guix are operating systems (or Linux distributions)
Depends who you ask…I find that the projects aren’t exactly in a hurry to create clarity on the matter.
“Guix is a distribution of the GNU operating system.”
You could fool me with this!
Nix on MacOS is a relatively common and discussed usage of Nix.
That is fair enough, you could fool me with that too - It definitely used to refer to Guix as a transactional package manager.
Yeah, it’s just that you have to wade through half the comms being about NixOS.
I talked to a colleague where they had Nix adopted in a part of a large company and every time somebody mentioned it, first they had to create clarity what it was that the person was talking about (language, packages, OS or something else entirely).
It seems it’s reached 1.0 https://www.tweag.io/blog/2023-05-17-nickel-1.0-release/
I was using HCL to configure my service but it was getting in the way as well as being a fairly large dependency and I never quite got it right (eg my configs never worked the same way as say Hashicorp’s do, I am sure I didn’t grok something very well).
I recently refactored a bunch of the data model and switched to plain unmarshalled json for configuration. It’s a lot more verbose of course but directly maps to the data structures being configured and is much clearer than the half baked DSL I was trying to define using hcl.
For the verboseness I have grand plans to produce a library/schema[fixtypo] in Nickel to generate the json for my configuration that should tame that somewhat and it will (obviously) become an optional external dependency instead of compile time.
Does the 1.0 release that the things they mentioned as next on the Roadmap have all been added?
https://nickel-lang.org/user-manual/introduction#current-state-and-roadmap
I am not really sure, but I would expect that if those things defined their goals for 1.0 then I would expect the majority of those to be there.
Seems like it is not the case, those things items are not part of 1.0:
https://github.com/tweag/nickel/pull/1307/files
I’ve filed an issue for that https://github.com/tweag/nickel/issues/1306
I made a survey of config languages that mentions many of the projects they compare with:
https://github.com/oilshell/oil/wiki/Survey-of-Config-Languages
One more for your list: https://json5.org/.
Yes that belongs, feel free to add it under JSON! (the wiki is freely editable)
Edited.
I really don’t think YAML belongs in the stringy section. Its non stringy-ness is often a source of pain, but it’s real.
NestedText would be a perfect fit for that section though.
Please, put code examples in your home page.
I thought the same thing when first visiting on mobile. On desktop there is an interactive example. I’m not sure why it doesn’t show on mobile, but ideally there would be a static fallback code sample for mobile.
I’d love to see documentation on embedding, and some implementations in other languages (Go would be useful to me) would be nice. Otherwise, it’s hard for tools to use Nickel as their preferred config language.
Generally looks good and in the ML frame with
let rec … in
. I like that JSON, YAML, & TOML are all supported out of the box until there could be a greater adoption. The burden of all the type info aside, I would miss Dhall’s syntax (and Unicode!) though. Relatedly, I wonder why they went with=>
over->
or→
for functions–last language I recall doing that was ReasonML. Is it because these arrows are reserved only for type-level annotation? The only real issues I have with Dhall is the only good parser/interpreter is in Haskell so unless you’re writing Haskell or just planning to run likedhall-to-json
to generate a file or the simplest Bash script, it basically can’t be used (like transferring typed data within your own project, holding onto that typed information). Because of this, I think Nickel could have more immediate usability. I haven’t looked at it in ages, but now I wanna give it a go.Some context: https://github.com/tweag/nickel/issues/1157