Hacker News Reader

Comment by andrewla | Hacker News Reader

I'm very excited by all the attempts to replace Nix, but I don't think I'll be exploring this much deeper.

In my opinion the issue with Nix is that the data model is not crisply defined -- it's there, but hidden under a lot of goop that is the Nix language itself and the various assumptions and baggage that goes with it.

What I want is a primarily declarative syntax supporting a rich set of data structures, ideally a non-Turing set of primitives, with a much more intuitive way of gluing things together. So basically bash (or even sh) with a well-defined way of transmitting environment variables and setting up the environment.

The idea of importing a language that has broader support (typescript) as an alternative to the Nix language seems appealing at first, but typescript is such a high-dependency system that it's hard to get excited about it.

View on HN

I think that declarative configuration languages scratch the itch of a lot of developer brains, but in practice it doesn’t really matter and using more familiar languages is a huge benefit to devex that shouldn’t be overlooked if the goal is to be mainstream. Yes, it requires more discipline on the reviewer front not to create abstractions that are too powerful/footgun-y, but it’s totally possible to write clear, declarative code in a “real” programming language without artificial constraints.

This is pretty much the same stance many people hold about Pulumi and I never found it compelling there either. In that product's case, the core languages for writing expressions are the languages that IMO have some of the most dysfunctional dependency-management stories in industry (Python, Node/JS/TS, Golang).

Since part of the sales pitch of using a general lang is emphasis on code reuse, it rings kind of hollow for me there, and here too.

I'm not so worried about my disciplined coworker who just wants to help. If we were all reviewing his code I'd agree with you.

The people I want to help are those who are unknowingly reviewing malicious commits, and I think that declarative configuration languages have a part to play there.

This is solved in tools like Pulumi by having a declarative and auditable build artifact as an intermediate step that can be diffed. This seems to solve a lot of the security issues (and is generally a good idea anyway).

I would still prefer to debug terraform (which is a fair bit more declarative) rather than pulumi

flox is the best thing I know of for articulating binary dependencies (language runtimes, etc.), which is probably the sweet spot for nix anyways at the moment (i.e. as opposed to trying to build everything "With the One [Tool] to [Replace] Them All"). flox uses nix for its backend, but has a simple TOML syntax and is properly humble about what it can do -- but killer at it -- as opposed to promising the world.

https://flox.dev

There's also [devbox](https://github.com/jetify-com/devbox).

Tried a lot of them, and after a while I found the nix the package manager on non NixOS requires too many workarounds. Things don't just work. For example, installing alacritty requires an OpenGL wrapper. Neovim can't find libraries to build some plugins. Basically, anything GUI had issues.

In the end, `cargo install`, `go install` and download a release archive from github are simpler to script for most of the tools I use.

This has been a consistent problem for me as well; Nix is way too concerned about purity. I think it comes from a desire to make package installation fast by using prebuilt binaries. I personally could give or take the prebuilt binary concept; nice to have but I'm willing to pay the time cost to be able to run things on non-NixOS systems.

Starlark is widely used by Bazel and Buck. That would fulfill similar properties and build system folks have one fewer thing to learn.

Yes, and Bazel makes some very serious trade-offs in order to make starlark work. Notably, dependencies are referenced as stringly labels as a poor substitute for lazy evaluation (starlark itself has strict evaluation semantics).

This in turn requires additional tooling to catch errors early, and also means that a starlark-repl for Bazel will never really be all that useful, since the build graph doesn't exist in starlark alone.

In my experience, this makes Bazel a significantly harder build system to truly grok, tho perhaps easier to use it without understanding it.

Contrast with nix, where the entire build graph exists as a nix expression. In my experience, you can gain a surprisingly deep understanding of nix armed only with knowledge of nix-the-language (and without knowing any implementation details of nix-the-binary-that-builds-derivations).

Agreed on all counts, especially the central issue with nix and the properties that I'd want out of a replacement. I think CUE ( https://cuelang.org/ ) is a perfect language for this.

Cue is fun, but already the unification example (https://cuelang.org/docs/tour/basics/duplicate-fields/) shouts "footguns" to me :(

TS is certainly excessively powerful though.

I don't think this would be a problem in practice. By default structs are "open" in cue, i.e. as long as matching fields unify, disparate fields just merge. There are also "closed" structs that allow creating a definition that fails to unify with fields not explicitly listed. https://cuelang.org/docs/tour/types/closed/

What foot guns are you seeing specifically?

Go find a place where the struct value is clearly defined.

It may seem that any definition is final, but none is. Since the last definition of a struct field overwrites a previous one, the order in which e.g. files are interpreted matters. It's like writing a config by using Python dicts, with the added complication that creation of a new one and updating of an existing one are indistinguishable.

This may be okay in practice, given some discipline.

No it cant overwrite values. It has to agree or it will throw an error.

You can have wider types being overridden by more closed types. e.g. string => "this literal". But you cant have two disagreeing values.

I use this to create kubernetes manifests at work, at a reasonably large scale. The inability to join multiple files without fear of collision is specifically one of the best features.

As someone who works with Kubernetes every day and has been curious about CUE for some time, can you describe a bit how you're using it to create manifests? Did it replace helm for you? Or is it to create CRDs?

Edit: I'm struggling to see where it fits in the whole k8s ecosystem.

It creates all the stuff that isnt in helm charts already for me. Im probably abusing it at the moment but ill see if I can make a gist and post the link. Bascally though I have a single massive package with a monolithic object. That goes env -> namespace -> resourceName -> resourceType -> resourceManifest.

Then I have a tool file that loops through that and renders it into fall files. Then argocd picks that up in chunks with application files.

Its awesome cause it lets me set project wide defaults and restrictions. It also lets me do stuff like. "If there is at least one manifest called x create an argocd application for it automatically" or " loop through these repos and create an app for each one with the following properties"

Hmm, looks better this way!

Reply on news.ycombinator.com