rgoulter

> overly verbose and flowery AI slop prose

This is a useful criticism.

Left to themselves, LLMs prefer writing that's really atrocious. e.g. The writing will try and make everything sound profound.

The other problem I've noticed is e.g. LLMs will write in stuff that's inappropriate for the content of the text. e.g. Writing out stuff that looks like a chat reply, in commentary or descriptions or whatever.

I'd distinguish, though, between "sloppy writing" & "LLM generated writing". I'd agree if you didn't put in the effort to check the writing is of high quality, then perhaps the other parts are also not high quality.

I don't think just because "AI" wrote it it's bad. I wouldn't prefer e.g. sloppy human writing over well-crafted LLM-written text.

This readme the main thing which sticks out is the "what you get" bullet points are rather dense/verbose for bullet points. But aside from that it seems fine.

It's a similar trade-off to using Terraform to manage a resource, compared to just modifying some cloud resource directly.

You pay a higher upfront cost, but you end up with declarative code which has advantages for maintenance.

With NixOS, rollbacks from changes to system state are trivial; and the whole system is configured from a single starting point, which makes it easy to track down why things are a certain way.

For a personal workstation, it's not necessarily a practical trade-off.

> Just remember that NixOS is only for personal and hobby use cases, as it is maintained by a large community of people that can ship any code they want without review, anchored on the honor system.

This is somewhat inaccurate, and loosely written.

It would be more meaningful to talk about the nixpkgs repository. If you wanted to, you could use Nix with your own vetted nixpkgs codebase.

Whether there are any contributors who can merge without review I'm not sure, but the typical path for contributions is to go through review.

Depends on the scale and confidence you want.

In systems where I've taken complex inputs and transformed it into complex outputs, I'd make it as easy to bring each particular pass under test, have snapshots that the same transformations resulted in the same outputs (insofar as I did want that consistency).

I'd think with a compiler, though, it can still be practical to describe the input you depend on as a value.

In distributed systems, your service might rely on another service which might be broken, might return different values than you expect, might return slower than you expect, etc. and so testing the parts of your system which depend on other services can be tricky.

Point is, you can arrange a lot of your code into "it's easy for me to ensure this part works", and you can see wins from that, even if as a whole the full system can be difficult to bring under test.

> The point isn't some people not understanding whatever stuff with limited effects, it's no people understanding anything important.

Using an LLM doesn't mean "I must write this code in a way that I cannot understand it". I'd encourage using the LLM to write code in a way that you can understand.

> When corporations own it exclusively, they can do whatever they want with it.

This is an argument in favour of open-weight models.

> Well, no, for a lot of us, there really is no other side. Slop farming is not software engineering and it never will be; scribbling some Markdown that begs agents to omit bugs is not equivalent to using high-level languages with thoughtful abstractions to directly define program behavior.

Would you look at a piece of code elegantly using high-level abstractions to model some problem written by a human and go "see, look, code is beautiful"... and then look at the exact same code written by an LLM and say "this is slop"?

> Moreover, it's downright offensive for a purported expert to defer their expertise to a SAAS black box.

With programming, it's just the opposite, though.

Programmers work with abstractions. Understanding the full system down to how atoms work is too much to think of when e.g. writing an API handler. So instead you work with modules and their interfaces.

Pre-LLM, if you need some task done, you wouldn't write it all out yourself if there was some external package which did the work for you.

Of course, when using an LLM, you don't need to surrender your ability to think about the problem and solution.

You want tests to be obvious "at a glance". And then some of the tests should at least indicate it's covering (for the most coverage of the system it reasonably can) the cases we care about.

The name of the test should indicate what it's doing.

For unit tests, these should check only one thing, and the test can be structured into "assemble, act, assert" style tests.

On the implementation side: code which touches state is tricky. -- So, minimize the amount of code which touches state (or rather, shift as much code as you can to stateless code, which is easier to bring under test).

I think this is worth elaborating on a bit.

I think any of the "JSON + functions" configuration languages mentioned in this thread (there are many) would be just as good.

Writing configurations in a modular way is really neat to be able to do. Rather than having to manage a single YAML file with the resource manifest, you can construct the resource by combining different parts of it.

e.g. rather than { image = "backend", tags = ["backend"] }, { image = "cache", tags = ["backend"] }, you could factor out the `tags`. -- Doing this from a "JSON + functions" language makes more sense than Helm's approach, from my experience.

The module system that NixOS uses builds an abstraction over this: each module declares like { options, config, output }. So the module author defines the option & output, and the module users declare the config, then the system knows how to render the configuration.

Zero-calorie drinks like coke zero provide a no-calorie alternative to the full sugar drinks.

If you habitually drink 3 cans of coke a day, and want to lose weight, then switching to coke zero is practically the same benefit, but consumes 430kcal less. Since coke zero is like a zero sugar replacement for typical coke, it makes sense to use "compared to coke" as the baseline.

That's what I meant by "clearly .. nutritionally beneficial". If you'd prefer a different term, then sure.

(I think the proposed alternative of "just eat whole foods and water" is surely going to be even more beneficial, but also requires a change in habits. If "change habits" was easy, I don't think there'd be any discussion around "Ultra Processed Food")

Some parts could be smoother.

Here's a rough sketch: the Nix expression language is really configuration oriented; it's a "JSON + functions" kind of language. You write Nix to describe how a package is built; the ideal case being "./configure && make && make install" as such. The resulting packages are put in a Nix store. (Almost) every dependency is put in the Nix store; so your program links against libraries in the Nix store, or runs other sources from the Nix store.

- Nix is "just" declarations of those instructions which output into directories and everything gets symlinked. But, it can take time to build an intuition for how to do things.

- There's some fundamental friction where most Linux systems assume shared libraries are available globally in a typical place on Linux. -- e.g. Python's "wheels" come with precompiled dependencies which assume shared libraries are available in a global place. Nix doesn't provide that.

- "Why not just provide globals?" For one, by having everything not be global, you can have multiple versions available at the same time.

- Since Nix is quite 'strict' by default about everything coming from the Nix store, it practically means 'paying' for all the difficulties up front. (There's a trade-off where you could write packages in a less strict manner; this is great for iterating, but bad for maintainability).

- Since Nix is strict about symlinking all dependencies, often if upstream software does things in a "quick and dirty manner" (e.g. hardcodes "/bin/bash", hardcodes paths for binaries to run, etc.) then it can be difficult to describe how to package that software with Nix. -- Fundamentally, you're taking something which works loosely, and bringing it into a stricter system.

- Upthread the comment mentions "flakes". Flakes provide both dependency management (i.e. being able to declare other Nix codebases you'll use), as well as a standard entrypoint into a Nix codebase. -- Without flakes, the UX is a bit cumbersome..

- The majority of packages which people use come from "Nixpkgs" package repository. This has a lot of organic complexity to it, coming from multiple contributors, with competing ideas for achieving results.

- With Nix being a "json + functions" language.. not sure I'm articulating this right, but it means that practically a large codebase is built as a single 'expression' (i.e. soft boundaries between bits of code).. and the tooling for troubleshooting problems is ... not very good.

- The Nix expression language is functional and lazy. This can be rough for people who don't have this background.

- Since Nix adds a layer of abstraction, it means you might need to have both a broad and a deep understanding to get something working (e.g. understanding how to drive Python or Linux in non-conventional ways). -- A kind of "do everything properly" which more conventional systems don't require.

So ... some aspects could be easier. But I think there's a fundamental friction to it.

A major concern raised in the article is along the lines of "passkeys have technical mechanisms that may disallow use in future".

That ... doesn't seem like a concern unique to passkeys, though?

It seems more like a policy rather than a technical aspect.

e.g. A website might decide they will only provide services if you upload a photo of government ID, or pass a verification where you show your face.

If it's software running on someone else's computer, you don't get full control regardless.

It's kinda a question of scope.

If your concern is about your own health as an individual? I want to lose weight now? I think it's useful to say "I have agency, I can lose weight". If you have the agency to lose weight, it makes sense you can take on the responsibility for having gained weight.

"Why did society in general get fatter?" is a different question. And if your main concern is "how can I lose fat?" it's not directly interesting.

Some tools are good even though they have a high barrier to entry.

That people use resources to help them use tools they don't understand too well is hardly new. e.g. Classically you might copy-paste from StackOverflow after finding an error, or some people watch YouTube videos about it.

I'd say LLMs make it easier to get to the point where you can understand it, though. So it's an accessibility increase.

> It remains so, only now you want people to blindly trust LLM output for this system.

This isn't related to Nix, though. You could ask an LLM to create the most mainstream Python code ever and blindly trusting it would make as much sense.

For system management, Nix has the advantage of being declarative. e.g. For NixOS you get to read the code and review what it's doing.

It's not so strange.

Pre-LLM: Nix is "high effort, moderate reward". The cost is: you have to learn a tool which does things apparently completely different to how other tools do things.. you have to put up with a lot of friction, pay all the pain upfront, and the benefit is that may be later it's easier to get the package again.

It's just not a practical trade-off for most developers.

With LLMs, the cost-benefit trade-off changes.

You can use this cloud provider's LLM to get you a good result. You get the benefits, and the cost is 'just' "ask the LLM to do it".

Similarly: it's easier to assess whether produced code does the right thing, than to come up with that code from scratch.

Without LLMs? The inaccessibility also comes from being a niche tool. Not many use it, so not many software projects accommodate it or consider it, and you might have to come up with workarounds yourself.