[jarym]

I love seeing stuff like this that would probably not exist if not for LLMs making exploring these kinds of ideas relatively cheap and quick to do.

My takeaway from this though is that nginx is pretty impressive on its own. Also this stuck out:

It's meant to be an alternative to nginx and Caddy, and the design bet is about configuration. Those servers give you a declarative config language - location blocks, rewrite rules, map directives, try_files - and then, once the declarative language hits its limits, an optional scripting runtime bolted on the side (Lua, or Caddy's plugins). Behavior ends up split across two layers: directives that quietly grow their own control flow, plus scripts that run somewhere in the request lifecycle you have to keep in your head.

I think the bet is misplaced - people prefer configuration over code and long have. The built-ins meet enough peoples needs entirely and they don't need to write C code.

[BobbyTables2]

I wouldn’t be so sure.

Seems like every configuration file format starts off simple. Look at YAML - the basics started off pretty sensibly.

And then people decided they wanted to get fancier with anchors and aliases. Even GitLab has its own form of conditionals and variables, which is all a bit of a hack (only works in certain places).

Even Apache fell into this with its XML based config format.

So we end up with numerous “bespoke” programming languages for configuration management. Of course enterprise people don’t edit these directly - they script Ansible workflows to remotely perform the surgery.

Sadly, could have skipped all that and just have embedded a Lua/Python/etc. interpreter into servers to do the configuration management. Would be simpler than trying to programmatically edit bespoke config files.

Sure, one will say all the bespoke attempts are optimized for a specific use the way a general language isn’t. Except that only fits a narrow class of toy examples which wouldn’t have needed their machinery in the first place!

Remember Windows INI files? Back in the good ol’ days when code was code and data was data….

[jasonjayr]

I'd wager that in the next 96 hours, with a LLM, someone could create a translator that would 'pack' a nginx or caddy configuration file into the relevant code that zeroserve could use. Or even more simply, just pickup all the Ingress manifests in a kubernetes cluster and rebuild the pack. The point being, the interface between the tool and the configuration is just another API, system operators are already describing the state of the system at higher level constructs, and the specific bytes that make up the configuration are an artifact of that.

[NewJazz]

Are you wagering that "someone could" or "someone will" do this? How much are you willing to wager?

[lelandbatey]

I suspect it's worth exploring if that will change as AI is allowing more and more "human words -> machine effect", which may be more ergonomic for the AIs. It could take a long time for that kind of shift to become clearly a good idea since the AI can make either work.

[high_priest]

What about abstracting the complexity and achieving "config file" configuration with macros?

[ai_fry_ur_brain]

Why are you so eager to credit LLMS.. Just because they wrote the article with the help of an LLM doesnt mean they're out here having LLMs do the experiments for them.

[simonw]

The commit history shows plenty of coding agent involvement: https://github.com/losfair/zeroserve/commits/main/

[zuzululu]

because it makes it easy to create/reverse engineer projects/explore on a whim without putting up a lot of time

LLM enables a lot of good output if you know what you are doing

[antonvs]

Bayesian inference suggests otherwise.