Meanwhile, I peek at my emacs config and continue to wonder why people don't just embrace a programming language.<p>Yes, there are bad consequences that can happen. No, you don't dodge having problems by picking a different data format. You just pick different problems. And take away tools from the users to deal with them.

Imho the best configuration file is one written in the language itself.<p>I love strongly typed configuration files like those in TypeScript (vite, nuxt, playwright). I love that they are generally defined as some `defineConfig` which an take an asynchronous callback.<p>Another great example is zig. The zig build configuration is just zig code, and is light years better to use than any alternative.

Sounds interesting as a format, but the implementation is a big supply-chain attack risk if you're not already in the JVM ecosystem.<p>This is because the only implementation is written in Kotlin. There are Python and Rust packages, but they both just link against the Kotlin version.<p>How do you build the Kotlin version? Well, let's look at the Rust package's build.rs:<p><a href="https://github.com/kson-org/kson/blob/main/lib-rust/kson-sys/build.rs" rel="nofollow">https://github.com/kson-org/kson/blob/main/lib-rust/kson-sys...</a><p>It defaults to simply downloading a precompiled library from GitHub, without any hash verification.<p>You can instead pass an environment variable to build libkson from source. However, this will run the ./gradlew script in the repo root, which… downloads an giant OpenJDK binary from GitHub and executes it. Later in the build process it does the same for pixi and GraalVM.<p>The build scripts also only support a small list of platforms (Windows/Linux/macOS on x86_64/arm64), and don't seem to handle cross-compilation.<p>The compiled library is 2MB for me, which is actually a lot less than I was expecting, so props for that. But that's fairly heavy by Rust standards.

KSON proudly claims "no whitespace sensitivity", which means "misleading indentation" is back. And it's pretty light on syntax, so there are going to be plenty of mistakes made here.<p>Here is an example I made in a few minutes:<p><pre><code> ports: - 80 - 8000 - 10000 - 12000 - - 14000 </code></pre> Guess how it parses? answer:<p><pre><code> {"ports":[80,8000,10000,12000,[14000]]}</code></pre>

The people behind KSON are geniuses. No joke. I worked with Daniel. And he's an amazing human too. Congrats on launching!!!

Configuration files need to be powerful programming languages (in terms of expressiveness) while being restricted (in terms of network and I/O and non-determinism). We need to aim very high for configuration languages especially when we treat them like user interfaces. Look at Cue (<a href="https://cuelang.org/" rel="nofollow">https://cuelang.org/</a>), Starlark or Dhall (<a href="https://dhall-lang.org/" rel="nofollow">https://dhall-lang.org/</a>) for inspiration, not JSON, unless your configuration file is almost always written programmatically.

JSON5 is good enough that it works for frontend devs, backend, qa, firmware, data science, chemists, optical engineers, and the hardware team, in my org at least. Interns pick up on it quickly.<p>The comment option gives enough space for devs to explain new options flags and objects included to those familiar enough to be using it.<p>For customer facing configurations we build a UI.

From the application point of view, recently I'm converging on this: define data structures for your config. Ensure it can be deserialized from json and toml. (In Rust this is easy to do with Serde; in Python with Pydantic or dataclasses.) Users can start simple and write toml by hand. If you prefer KSON, sure, write KSON and render to json. If config is UI, I think the structure of the data, and names of fields and values, matter much more than the syntax. (E.g. `timeout = 300` is meaningless regardless of syntax; `timeout_ms = 300` or `timeout = "300 ms"` are self-documenting.)<p>When the configuration grows complex, and you feel the need to abstract and generate things, switch to a configuration language like Cue or RCL, and render to json. The application doesn't need to force a format onto the user!

Having now worked with terraform for 8 years, I could not agree more. Now, also because of having worked with terraform for 8 years and seeing how that's played out, I've heard and become tired of the whole "superset of json, transcribable to YAML, whitespace is not significant (which has never been a gripe of mine ever, not sure why every product cares so much about that)" promise of a silver bullet, and you very much face the same exact problems, just in different form. Terraform (HCL, to be specific) in particular can become fantastically ugly and verbose and "difficult to modify."<p>Configuration is difficult, the tooling is rarely the problem (at least in my experience).

Has anyone used both kson and hjson? We use hjson as a more forgiving json-like config format and really like it. kson seems more feature rich, but I'm a bit concerned about things like embedding code in configs. So any thoughts vs hjson?

Came across hocon recently and prefer over both yaml and kson. <a href="https://learnxinyminutes.com/hocon/" rel="nofollow">https://learnxinyminutes.com/hocon/</a>

I think it is telling no programming language has settled on YAML or JSON as a syntax. Because that would drive you nuts.<p>But we allow it for files that tend to make production changes usually without any unit tests!<p>I'd prefer something syntaxed like a programming language but without turing completeness.

I like where their head is at here, especially the "superset of JSON" part. Some of the things I'm not _in love_ with like the %% ending blocks or how maybe a bit of significant whitespace might make things a bit less misleading with indentation as others have said, but overall I think I like this better than YAML.

KSON looks interesting. Where I work we did a metadata type project in Pkl recently, which is somewhat similar. Unfortunately, developments on the tooling front for Pkl have taken an extremely very long time. Not sure the the tooling/LSPs are anywhere close to what the language offers yet.<p>I like the language embedding feature in KSON - we would use that. Have you thought about having functions and variables? That is something you get in Pkl and Dhall which are useful.

This is why Caddy has config adapters: bring any config file language you like, and Caddy will run it. It's built-into the binary and just takes a command line flag to switch languages: <a href="https://caddyserver.com/docs/config-adapters" rel="nofollow">https://caddyserver.com/docs/config-adapters</a>

With all the code syntax highlighting support as a feature, I feel it will become tempting to put code in configuration files (which some of their examples show). That just feels wrong. Code should go in code files/modules/libraries, not mixed with configuration files. If your configuration starts to become code, maybe you need to rethink your software architecture. Or perhaps KSON proves that principle to be too rigid and inferior, and leads to more intelligible, manageable software. I guess we'll have to see.

There’s two configuration that I like:<p>- The key-value pair. Maybe some section marker (INI,..). Easy to sed.<p>- The command kind. Where the file contains the same command that can be used in other place (vim, mg, sway). More suited to TUI and bigger applications.<p>With these two, include statement are nice.

KSON looks neat.<p>I think the post is hurt by the desire to sort of… “have a theory” or take a new stance. The configuration file is obviously not a user interface, it is data. It is data that is typically edited with a text editor. The text editor is the UI. The post doesn’t really justify the idea of calling the configuration file, rather than the program used to edit it, the UI. Instead it focuses on a better standard for the data.<p>The advancement of standards that make the data easier to handle inside the text editor is great, though! Maybe the slightly confusing (I dare say confused) blog title will help spread the idea of kson, regardless.<p>Edit: another idea, one that is so obvious that nobody would write a blog post about it, is that configuring your program is part of the U<i>X</i>.

While I agree with the general idea, 2 minutes of looking at KSON was enough for me. If this is UI, it’s an ugly one.<p>I’ll stick to JSON. When JSON isn’t enough it usually means the schema needs an update.

My personal opinion is: If your config needs to be so complex you can't make do with TOML you should just use a interpreted programming language instead. It is totally acceptable to use a config.py for example. You get lists, dicts, classes, and all more or less known and well behaved and people can automate away the boring stuff.<p>But I'd strongly encourage everybody to think about whether that deep configurability is really needed.

yes but to validate it you need dynamic runtime logic and therefore a live server with all the I/O glue code that entails. i.e., static types alone cannot render your tax forms

Or you just use YAML. It's a configuration language for your software, you control which parser you use which can be YAML 1.2, you can use the safe loader which can't run untrusted code, and you're parsing the values into your language's types so any type confusion will be instantly caught.<p>I agree that it's not perfect but worse is better and familiar is a massive win over making your users look up a new file format or set their editor up for it. If you truly hate YAML that's fine, there's plenty of other familiar formats: INI, toml, JSON.

Yes all user interfaces are a key/value list.<p>That’s why 90% of each iOS update is just another menu or a reorganization of menus and why there are 3 different ways to access the same info/menus on iOS.

Anecdote: I am still of the opinion that in most (~99%)[1] of the situations people are in "YAML Hell" because they put themselves in "YAML Hell".<p>1: I pulled that out of my butt, there's no factual data to it.