[FriedrichN]

I'll just come out and say that I hate every single configuration language. All of them suck in their own unique way and every time a new one comes out it fixes some issues of the language it's supposed to supersede but never without introducing new problems. And eventually you're left thinking that you should've just used a .ini file.

[solatic]

"Configuration" languages are fundamentally necessary and it's tragic that people don't understand why.

There are declarative and imperative paradigms. Software engineering layers them on top of each other. Frontend devs write imperative TypeScript to manipulate declarative JSX, which instructs a React library to imperatively decide how to layout declarative HTML, which instructs a web browser to imperatively decide how to render, and so on. The frontend sends an imperative API call to a declaratively-specified API gateway, which imperatively forwards a declarative request body to a backend service, which imperatively goes through validation, authorization, etc. before submitting a declarative SQL SELECT to a database, which imperatively plans out a query over declarative representations of data on the disk, sending imperative system calls to the kernel/disk controller, etc.

Python, JavaScript, Rust, Go.... these are all fine programming languages that allow expressing an imperative paradigm.

But we have fewer languages for declarative paradigms. So-called "configuration" languages are attempts to build higher-level declarative paradigms. Nothing more, nothing less. We need higher-level declarative paradigms to build on top of the current imperative paradigms. It is the next step in the march towards more power and expressiveness, and therefore more productivity and ease of maintenance.

[masom]

yup.

TOML gets pretty close to a `.ini` file as a standardized parser, taking the original format idea a little bit further.

https://toml.io/en/

[XorNot]

I hate TOML. It's even worse at expressing maps and sequences then YAML, which is actually quite good at it.

[loloquwowndueo]

Well .ini files also suck so what are you going to use now? :)

[FriedrichN]

They absolutely do. But I usually don't have to explain the config language and it's widely supported, that is an absolute upside of .ini files.

[NeutralForest]

Agreed and they don't have good escape hatches. What was supposed to be declarative always ends up requiring some logic here and there and then you're stuck with a terrible language like YAML and you have to turn to templating, references to anchors and whatnot.

What I don't like is when you need to use a configuration language like Bicep or Terraform when the underlying architecture cannot be represented declaratively. You can create resources and provision them, that's fine. But any time you need forking paths, specific conditions, iterations over some resources, etc. You're done for, unless the configuration language has built a command or keyword for your specific use case. You can always tell me that I'm holding it wrong but when the platform requires me to use those config files or the SDKs for whatever languages are useless, it's infuriating.

Side note and not related to configuration languages but how they're used on $cloudProvider. But when you declare resources or operations that are legal in the language but invalid on the plateform, I die a little bit inside. The platform has all the knowledge about the existence of resources, policies, behavior; there's a whole class of problems that shouldn't exist before you're even trying to run a pipeline!

[rad_gruchalski]

I like how you shifted the goal post from “I” to “you” to justify your point of view. I don’t care, give me yaml, toml, json, jsonnet, ansible, who cares. It’s a tool. I’m not married to it.

[FriedrichN]

I'll use what I'll have to use, it's a tool like you said. But I don't have to love it. Configuration is a necessary evil and whatever I end up using, I'm never fully satisfied with the end result.