Hacker News Reader

Comment by verdverm | Hacker News Reader

JSON does not have comments, no JSON5 is not the answer either

Think bigger, it's not something you are using today. The next config language should have schemas built in and support for modules/imports so we can do sharing/caring. It should look and feel like config languages and interoperate with all of those that we currently use. It will be a single configuration fabric across the SDLC.

This exists today for you to try, with CUE

I've been cooking up something the last few weeks for those interested, CUE + Dagger

https://github.com/hofstadter-io/hof/tree/_next/examples/env

View on HN

Like XML? :)

Like Python?

CUE

Why not Python?

Typing is bolted on rather than a native concept, for one.

Why is that a problem?

Because types are important and having them be a native part of the language creates opportunities for error checking, editor completions, and LLM bounding.

Invisible scoping and turning complete

Python is better than bash in ops, been using more Go in this space

Config is another beast and separate languages

I’m not sold that config is a complex enough domain to necessitate another language. What problems is CUE solving when compared to python and why are those problems substantial enough to make it worth learning a new language?

That's exactly the thing -- complexity. Cue bounds complexity, like json, yaml, and toml. But it offers more composeability than any of them.

Given that we now have TOML, JSON, INI, CSV, YAML, etc it seems we are converging on either JSON, YAML or TOML. There is too much inertia behind those three and not much behind CUE right now.

CUE works with all of those languages, so it doesn't matter what the tools or others are using. I can always apply CUE at any point to output their required format as needed.

Keep your legacy config and mess if you want, you're the one missing out

Also, I don't see TOML in the wild enough and the others have been around long enough, I must chuckle and not take seriously these claims about "inertia"

I’m not claiming inertia makes TOML ‘best’, just that it’s clearly not blocked by inertia either. Cargo standardized on TOML years ago, and GitLab Runner has relied on it for a long time. If a format can win in major ecosystems, “people won’t adopt anything new” isn’t the whole story.”

I genuinely despise the identing requirements of YAML.

For comments, I use a _comment field for my custom JSON reading apps

I dislike the idea of _comment because it’s something that is parsed and becomes part of the data structure in memory. Comments should be ignored and not parsed.

When I wrote a custom deployment tool for some lab deployments, my Python based tool used JSON as the config language and comments were parsed I guess but not part of my data structure. They were dropped

yeah, this is what I'm talking about, innovation has stopped and we do dirty hacks like `imports: [...]` in yaml and `_comment` in json

How are people not embarrassed by this complete lack of quality in their work?

I don’t think we need anything formal resembling XML like JSON. It was originally meant for over the wire payloads and people like myself use it for more than that

You're still thinking "good enough". I'm advocating for the "we can do so much better" attitude

The current popular config choices cause a lot of extra work, bugs, and effort. Is improving the status quo not a worthy goal anymore? Are we at a point in history throwing our hands up and saying meh, I deal with this... is basically where people are today? (I'm somewhat a believer of this based on anecdata and vibes)

The uncomfortable reality is that config formats don’t win by being best. They win by being:

1. already installed everywhere,

2. easy to parse in every language,

3. supported by editors/linters/CI tools,

4. stable enough that vendors bet on them.

The config language we write does not have to be the same thing the programs read. Same analogy to compilers and assembly

Reply on news.ycombinator.com