Hacker News Reader

Yeah I think the difference ultimately is the API surface of infra versus app software. If you're developing software, you get to contain and abstract everything into your own vision of how things should be done with types etc. But infra is managing a whole bunch of other people's software, each with their own vision of how things should be done, which means that often things just fall back to the least common denominator, plain ASCII

> basic CRUD application with a basic SQL database

The whole problem on the infrastructure side is that the APIs are slow and you don't have exclusive access. Building the CRUD app would be a million times harder if SQL calls took 100x longer to execute and other people could randomly reach into the database and change the schema and data at will - can your basic CRUD app gracefully handle somebody shoving newlines at the end of usernames? Odds are that the first time, no, not until you put a trim() call. And then you cry in pain at needing to put trim() calls everywhere. And then you gnash your teeth at people reporting performance problems because of all the defensive checks you put in because all trust has been thrown out. And then you find out that trim() was deprecated and will now be replaced by strim() that handles Unicode a little differently, and you need to port your code before End of Life to stay compliant.

A basic CRUD application with a basic SQL database doesn't solve the problem, because you don't seem to appreciate that there already is a database - however your vendor stores configuration - and it's your job to deal with it. Adding another database on top of it would make the problem worse.

Let's have a toy example. You want to store some information about some software configuration and let users view it. Some fairly basic data.

If you are infrastructure software minded, you might store the data in files that are stored in git. For users to read the data, they can perhaps browse the repo or clone it. For some more complex questions you might have a document which tells the user how to fire a CI pipeline that runs some code over the data and the user has to read the pipeline logs to get the information. The CI pipeline will probably run in a container which will produce a large log and take a long time to start.

If you are software software minded, you store the values in a database, make a service with a REST or some other API and create a browser UI. User can browse the data in a table view and perform searches and perhaps there's some more complex business logic executed on the backend to get answers to some more complex questions.

In this case, both systems can easily do the job. But the solutions are very different.

Infra folks can absolutely build self-service UIs and I have seen it being done even before AI, for instance using low-code tools.

> It's very error prone to describe a hierarchy of versioned software packages and configuration with shell scripts and yaml.

We have a multitude of configuration/markup languages all doing the exact same thing.

We have solved this problem in the 60s: S-Expressions. Should have just used that for everything. Configuration, code, websites, you name it. Infinitely extendable, easy to parse.

I'm a lisp nerd, but why do you say sexps are the answer here? I think the point of a lot of configuration formats is that they don't want their configuration to also be a full-fledged programming language.

> they don't want their configuration to also be a full-fledged programming language.

They say they don't want it but every configurmation format eventually ends up becoming turing complete at some point.

There has been some config languages, like Cue, that are not Turing complete. It is useful of have them always complete and have deterministic evaluation.

Cue also has a lot of schema validation which is better than dynamic languages.

> I think the point of a lot of configuration formats is that they don't want their configuration to also be a full-fledged programming language.

That seems to be everyone's initial goal, but then it inevitably gets leaky.

I think the dominant split here that forces everything into a weird mismash is that nobody really wants to have to understand arbitrary programming language configs for third-party stuff, they want to read config and know what's going on. BUT for their own stuff, they find reasons to want more power and expressibility...

> That seems to be everyone's initial goal, but then it inevitably gets leaky.

This is very much true. And until they do get leaky, you have to wrap them in all sorts of weird templates or other forms of abstraction.

This is one of the reasons I used to really like Chef's config language. It was a Ruby DSL, which meant that anything the DSL couldn't do natively, you could just use Ruby right there.

Of course, this is easily misused, but if you were careful it was as powerful as it was elegant.

Sexps, on their own, are not a programming language.

I’m aware.

Going in a completely different direction, Haskell could make a nice, powerful configuration language.

If it compiles, it’s almost certainly correct.

This idea exists (as in a functional language which is used for configuration), and it's called Dhall (https://dhall-lang.org/). But they made it a total language so that it has stronger guarantees of terminating and lots of other config specific stuff.

I personally have dealt a lot with S-expressions, and at this point, given the amount of tooling, I think JSON is just almost always the right choice. It parses fast with SIMDJSON or doing various other approaches to parse sparsely. It's a little under-specified in terms of stuff like number precision, but you can honestly write your own JSON parser which does >600MB/s with an LLM in one shot and do whatever custom validation you want these days. And you get unambiguous maps without having to glean from adjacency list structure like in sexp.

And if you really love sexps, then writing a bunch of arrays in JSON is also viable. If you asked me 10 years ago I might've complained about JSON, but now I think we messed up by having a bunch of other formats, tbh. I have my own TUI JSON editor that can render in tree view, miller tree view, flat view, and inferred table view, and it makes editing JSON very easy too.

Oh and duckdb can query against compressed json and jsonl at GB/s

How would you create a configuration file with S-expressions? Wouldn't it require defining operators and a parser?

It no longer applies at all, and in retrospect might look silly, but a core principle of "infra as yaml" and "infra as piles of plain-text files in git" was that infra was supposed to be dumb.

A reliability engineer's nightmare, and a common one, is stepping into a company whose deployment pipeline is built in-house, with dynamic bespoke software. What happens when Jeff leaves to build his own startup and absolutely no one knows how that Node.js script shells out to SSH to call docker on a remote server? I can tell you what happens: everything works fine for awhile and then suddenly doesn't for awhile.

On the other hand, you join a company with K8s and plain-jane YAML and can instantly grok the entire system and fix prod on your first day while the S-team sweats behind you, watching every key stroke. The seconds I have to read some javascript or bash or perl are precious seconds the brand is suffering.

In software engineering, flexibility and abstraction is a benefit: the product must pivot and evolve. In reliability engineering we want dead simple, tried and true. You want to be able to step outside your SF office and say "Someone help me with EKS, my DevOps guy died last night in a car crash!" and have 4 people with wild hair take their weird off-brand not-air-pods out of their head and say "uhhh sure okay".

Does all of this change with AI? Yes. Did it make sense a year ago for business continuity reasons? Yes. Was it ever beautiful where the rubber hit the road? No.

Why aren't tires as complex as wiring harnesses?

> core principle of "infra as yaml" and "infra as piles of plain-text files in git" was that infra was supposed to be dumb.

The problem is that that's not true in practice. It's a myth, and always has been for all but the most trivial setups. Infrastructure is now highly dynamic and, like old cities, becomes more complex, calcified, and non-uniform with age.

Infrastructure configuration is an excellent example of the blurriness of code-vs-configuration. I'm now several decades into my career, and I'd rather have pure code generate my configurations than some Frankenstein's monster of "mostly config but lots of code in there when it gets too complicated" UX. Config file formats always evolve into this mess eventually, and a lot of my fellow practitioners don't seem to recognize this problem, leaving the cycle to continue.