61–70 of 79 posts
It feels like Nix is crossing some kind of developer awareness threshhold. For me as someone perusing various tech threads, this feels like the year that, among developers, Nix is going mainstream.
Earlier quoted context omitted.
Can you clarify what parts you don't like. I think it's important to distinguish so I know what portions to work on (and figure out how to fix it). Is it: the language syntax itself, the idioms used in Nixpkgs, the module system, the common frameworks used to create package sets, or something else?
The language is in a weird place. The language itself is okay, but you're often trying to use the language to compute a result that meets an interface that is never defined. There is very poor ability to reason about the 'types'/shapes of arguments or the semantics of what outputs should conform to. It seems to require either 1) deep knowledge about the orchestration of the evaluation of the key files you interact wi…
A new configuration language designed to work with Nix, Nickel https://nickel-lang.org/ looks like a step in the right direction, but I think the language design of CUE https://cuelang.org/ is the largest local maxima in the expressiveness / complexity tradeoff that we've found. Nickel is inspired by CUE, but I'm concerned that they're stumbling over the design (#1121) due to missing one of the headlining features of CUE, the U: Unification.
It feels like Nix is crossing some kind of developer awareness threshhold. For me as someone perusing various tech threads, this feels like the year that, among developers, Nix is going mainstream.
- slow as hell on mac
- doesn’t work well with a project that makes use of Rust. We have weird rules for building and being able to dev with the Rust side (basically the devshell will try not to create a derivation for the rust stuff). Also every update of cargo.lock or rust-toolchain will break the nix install.
- doesn’t work well with my tools (vscode). There’s a nix env plugin but it doesn’t work with flakes. Direnv plugins exist as well but they didn’t seem to work for me.
- the shell doesn’t work without passing -i for me. Some env vars seem to break my nix
- the defaults don’t take mac into account, which is insane imo, I wrote about it here: https://mimoo.github.io/nixbyexample/
In general it feels like all the devs that are working on nix are not on mac, don’t use vscode, prolly don’t use Rust as well.
Earlier quoted context omitted.
Can you clarify what parts you don't like. I think it's important to distinguish so I know what portions to work on (and figure out how to fix it). Is it: the language syntax itself, the idioms used in Nixpkgs, the module system, the common frameworks used to create package sets, or something else?
The language is in a weird place. The language itself is okay, but you're often trying to use the language to compute a result that meets an interface that is never defined. There is very poor ability to reason about the 'types'/shapes of arguments or the semantics of what outputs should conform to. It seems to require either 1) deep knowledge about the orchestration of the evaluation of the key files you interact wi…
When I write Rust I understand exactly what structs I’m creating due to the typesystem + the excellent documentation. In Nix I’m always lost. What struct should my flake function return? What arguments can it take? Etc.
Earlier quoted context omitted.
The language is in a weird place. The language itself is okay, but you're often trying to use the language to compute a result that meets an interface that is never defined. There is very poor ability to reason about the 'types'/shapes of arguments or the semantics of what outputs should conform to. It seems to require either 1) deep knowledge about the orchestration of the evaluation of the key files you interact wi…
Flakes may be a step in the right direction, but I admit I've somewhat halted my journey after finally grokking how to use nix channels and configuration.nix. I haven't done any packaging or gotten into flakes as a unit of composable configuration. I know flakes are intended to make these things easier, but even the 'specification' for what makes a valid flake seems awfully vague.
So, I don't quite grok nix. Am I supposed to use it instead of Ansible and Terraform? Where does it fit exactly?
It’s sort of like a makefile, but it’ll always work and will setup everything for you to be able to build
For an average programmer or team, this stuff needs to be heavily, massively, streamlined / centralized to a single Best Practice.
The nix package search website is OK, but it doesn't let you filter by the names of installed binaries. A lot of the time, you have a question like "what nixpkgs attribute do i install in order to get the `python3` command". I recently wrote a command line tool that allows you to do this. It uses the same elasticsearch index as the search website, but allows more powerful filtering. If anyone is thinking of getting i…
Cool! I love Nix, but really am not a fan of the Nix package listing website. So, it is nice to see. And I guess worth mentioning, but if you or anyone else is ever feeling a little less lazy than me and want to add more available metadata, some of my main gripes with the official site: - No easy way to see dependencies without viewing the package derivation source code. - No easy way to see "reverse" dependencies, p…
nix-store -qR `which python`
> No easy way to see "reverse" dependencies, period, as far as I am aware, short of basically grepping the entire nixpkgs repo, and even then you won't get a totally accurate answer.
nix-store -q --referrers `which python`
This and many other querying commands are explained in the Command Reference of Nix manual. Have you read it? [1]
[1] https://nixos.org/manual/nix/stable/command-ref/nix-store.ht...
It feels like Nix is crossing some kind of developer awareness threshhold. For me as someone perusing various tech threads, this feels like the year that, among developers, Nix is going mainstream.
We just adopted nix at work so it def. feels like that from my point of view. If anyone reads this, here’s why I’ve been avoiding (and building without it) even though I wish I could use it: - slow as hell on mac - doesn’t work well with a project that makes use of Rust. We have weird rules for building and being able to dev with the Rust side (basically the devshell will try not to create a derivation for the rust s…
The direnv plugin works with flakes for me using sn envrc reading `use flake` and using the home manager package nix-direnv.
> In general it feels like all the devs that are working on nix are not on mac, don’t use vscode, prolly don’t use Rust as well.
I think this is untrue, especially for rust. I know vscode is pretty popular with nix users too.
I'd encourage asking for help on https://discourse.nixos.org. Maybe a separate thread per issue.