[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.

[demurgos]

What is the issue with TOML maps and sequences compared to YAML?

My main gripe was that inline tables had to be single line, but the restriction is lifted in TOML 1.1.0.

[Ygg2]

Seeing how YAML allows for keys to be objects (and often mutable at that), I can't agree with that sentiment that YAML is good at expressing maps.

[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.

[rad_gruchalski]

There’s no need to have any emotional connection to any tool.

[FriedrichN]

You are right. However, it is my work and I do have an emotional connection to my work and my frustrations with certain technologies are very real.

[monkey_monkey]

Similarly, there's no need to comment on this.

[rad_gruchalski]

Don’t comment then. You may not agree with me but I feel it is important to comment because it’s important to share an opinion shaping the path of new engineers joining the field. Tools are tools. Some are better than others. There’s no reason to have an emotional connection to them. Five years from now there will be new tools we never imagined we need. We are paid for getting the job done, not for an emotional opinion.

[monkey_monkey]

You seem to be the emotional one here, but hey, if it makes you feel better trying to police how other people react to stuff, then you do you, sister.

Also, what's this "we", just because you're being paid to be a robot doesn't mean everyone else is.