> Something like the JSON version of Terraform that can be generated by different tools, but an open standard instead.

God, please no. The worst thing about all these tools is the terrible formats they keep choosing.

Given the directions we’ve (“cutting edge” programmers and server ops folks) chosen to go instead, leaving XML behind was a big mistake.

I’d prefer something better, but yaml and json are so terrible that going back to xml would be an improvement.

You'd write in a language designed for humans, and that would get translated into a language for computers. In other words, JSON.

What are your reasons for disliking JSON?

Terrible, awful type system. And I just mean at the level of primitive types it can represent, nothing fancy. It doesn’t even have a date type, let alone things like decimals.

That’d be my argument specifically against using it to communicate between pieces of software—at least if you’re hand-writing it there’s the excuse that it’s kinda, sorta easy to read and write (at least, people say that—IMO it’s only true for tiny, trivial examples, but that may be a matter of taste)

My take on it as a hand-written config/data language is that it’s simply absurd. JSON-schema is terribly unwieldy, but also the lingua franca, so if you want to keep your sanity you write something better to define your data structures (probably in some actual programming language) and generate JSON schema to share structure definitions among readers. Oh my—why?

JSON isn't designed for humans. It's designed, originally, to be eval()d in a browser. HOCON is a JSON-type-system compatible language designed for human config files:

https://hocon.dev

I didn't express myself very clearly, my apologies.

I meant that you'd write in a human centric language that would then be translated to JSON. Not editing JSON directly.

> language designed for humans

Hardly - it's a hack as a data-only subset of JavaScript, as a sibling comment mentions.

It has no support for comments (even though JavaScript does). No support for optimal trailing commas. No integers. No enums.

I didn't write very clearly, my apologies.

I meant that you'd write in a human centric language that would then be translated to JSON. Not editing JSON directly.

Data formats don't typically have comments because they are (supposed to be) generated by machines and read by machines. The .DATA sections in binaries don't have comments... Network protocols don't have comments... Pickle files don't have comments... JSON is supposed to just encode data.

It goes like this:

- XML was created to allow humans to write human-friendly data encoding (AKA "markup") that had lots of features they wanted programs to take advantage of.

- It turned out the format they chose was great for the machines, but really annoying for humans.

- They refused to change the format for humans, so humans got sick of it, and decided the problem was it was "too complicated" (as opposed to merely "too clunky").

- So they created some other formats, which weren't in any way better, but were simpler, so they could ignore the fact that they made the formats too clunky.

- Some formats' designers were opinionated, and decided things like "comments are an anti-pattern in a data format", so they took those features out.

- So now humans could manage the formats better. But they still wanted programs to take advantage of useful features - like multiple data types. So they implemented multiple data types in the formats.

- But the humans forgot that humans are still pretty dumb, and that most people never read specifications. So the users of the new format would incorrectly use the format, and run into the different data types accidentally (like true/false or null in JSON, or "The Norway Problem" in YAML), and claim the problem was the format, and not their own ignorance of it. (isn't the human ego amazing?)

- So the humans, not having learned from history, invented yet more data formats, with even fewer features, so that they would not continue to screw up the things they themselves invented. And so you get things like "restricted yaml" or "toml" (which is basically an .ini file, a format from 50 years before).

A data format that allows comments is called a "configuration file", and is supposed to be primarily read and written by humans, and requires a machine to implement a parser for it. Those are not always easy to write, which is why most people today have chosen to use data formats rather than configuration formats. But that has the unintended consequence of humans not understanding that types in data formats are a thing.

Back in the day we wrote the configuration format for the human, and used data formats for machine<->machine communication. Some of those data formats were very easy for humans to read, but that was largely an accident of the fact that most programs had records so simple that we separated everything with newlines... not an engineering decision as much as a "hey, it's really easy to just read an entire data record as everything up to '\n'" thing.

Over time people have sort of become confused about what each format is and how it should be used, and what for. The data format churn (and constant griping) will continue, forever, because humans never learn their history.

Agree on YAML, disagree on JSON.

So basically you want OpenTofu. It's open source, you can make it do whatever you want, and there's a >0% chance your PRs will get accepted (compared to with HashiCorp)

Maybe you’d like Pulumi?