[crispyambulance]

> Infrastructure as Code, not infrastructure as YAML.

Right on.

It's amazing to me that we've spent decades with programming languages and environments which can accurately guess what you're about to type next, which have enormous expressiveness while maintaining cogency, which are intuitive and well understood by humans, which have endless libraries and an infinity of ways of connecting with the world.

And what do we use to configure the most sophisticated infrastructure to run such code? Yet another mark-up language!

[beagle3]

Many domains are better served by a more limited programming language, so you can analyze a program and/or make guarantees about it.

Real regexes (actually regular…) are infinitely better than Python code matching the same string (if they are sufficient) - you can compute their intersection, union, complement; check if they can match anything at all (and generate an example automaticallly).

For software builds, Bazel and others use Starlark, which is a restricted Python subset, so builds can be guaranteed finite and can be reasoned about.

Ansible may or may not offer any benefits in return for the limits (I am not an ansible guru), but in general, most tasks do not need a Turing complete configuration/specification language - and it is then better to NOT have Turing completeness.

[VectorLock]

The "you don't want a full programming language" trope I see repeated a lot but I think far more people end up wishing for a Turing complete language than wishing it _wasn't_ Turing complete.

[beagle3]

They do, until a configuration endless loop brings down their production system.

This is not really different than C vs Rust, or even Perl regular expressions (unbounded execution time) vs real regular expression. With great powers comes great abilities to shoot yourself in the foot.

The power/guarantee balance is delicate, and you can’t hold the stick at both ends. People will always complain.

[HALtheWise]

This is exactly what the Starlark language was developed to solve, initially for Bazel but also used other places. It's a "full scripting language" but intentionally doesn't (in default configuration) support recursion or unbounded loops, so is deterministic and bounded execution time. I really wish more projects would reach for it as a configuration language.

https://github.com/bazelbuild/starlark

[ssousa666]

I have such mixed feelings about Starlark and Bazel macros. When I write Bazel macros, they're great, the perfect tool for the job. When I encounter macros written by someone else, they are awful, a mistake and the bane of my existence.

[crispyambulance]

A lot of this is a matter of taste and judgement.

In the same way that it's possible to have an xml/json/yaml/toml config that creates despair in those who have to maintain it, a python or bash script can grow into a monster in the basement.

Or, it could be a cogent script that makes its intent and operation obvious. I prefer that when possible.

[xixixao]

The environment around the language can put in limits (on time, number of operations, etc.)

Convex does this well, replacing SQL (somewhat yaml-like sucky old declarative language) with JS/TS but in a well-locked-down environment with limits to ensure one mutation or query doesn’t take down the whole DB.

[VectorLock]

The number of times I've seen a configuration endless loop bring down anything are so few compared to the time wasted on DSLs and having to bend over backwards to do things a first-class programming language can do simply. Same with PCRE I've seen that maybe.. once.

[crabbone]

> It's amazing to me that we've spent decades with programming languages and environments which can accurately guess what you're about to type next, which have enormous expressiveness

You've almost guessed the problem. Too much expressiveness is a bad thing. This is a problem I encounter a lot more often then I'd be happy to. It's very often is much easier to build something more generic than what the user actually needs, and then testing it becomes a nightmare.

To make this more concrete, here's a case I'm working on right now. Our company provides customers with a tool to manage large amounts of compute resources (in HPC domain). It's possible to run the product on-prem, or in different clouds, or a combination of both. Typically, the management component comes with a PXE boot and unfolds from there. A customer wanted integration with a particular cloud provider that doesn't support this management style, nor can it provide a spare disk to be used for management, nor any other way our management component was prepared to boot.

The solution was to use netboot that would pre-partition the disk and use the first N partitions to store the management component as well as the boot, ESP / bios_grub partition etc. It had to be incorporated into the existing solution that encompasses partitioning and mounting all the resources available to a VM, including managing RAIDs, LVM, DM and so on.

The developers implemented it as a GPT partition name with a pre-defined value that would instruct our code to ignore the partitions found prior to the "special" partition and allow the user to carry on as usual, pretending that the first fraction of the disk simply didn't exist (used by netboot + the management component).

This solved the immediate problem for the user who wanted this ability, but created thousands of problems for QA: what happens if there's a RAID that uses the "hidden" partitions? What happens if the user accidentally creates second /boot partition? What happens if the user wants whole-disk encryption? And so on. It would've been so much better if these questions didn't exist in the first place, than to try to answer them, given the "simple" solution the developers came up with.

If you programmed for just a year, I'm sure you've been in this situation at least a few times already. This is exceedingly common.

* * *

There's an enormous value to being able to restrict the possible ways a program can run. Most GUI projects? -- They don't need infinite loops! It just makes programs unnecessarily hard to verify. But it's "easy" to have a single loop language element that can be made infinite if necessary. Configuration languages exclude whole classes of errors simply by making them impossible to express.

However, I have to agree that, specifically, YAML is a piss-poor configuration language. It has way too many problems that overshadow the benefits it offers. We, collectively, decided to use it because everyone else decided to use it, making it popular... and languages are "natural monopolies". So, one could certainly do better ditching YAML, if they can afford to go unpopular. But ditching the idea of a configuration language is throwing the baby out with the bathwater.