Things I don't like in configuration languages
48 comments
·November 17, 2025tikhonj
rdtsc
Agree, sexp is quite nice. That was my favorite before json came around. Not that I like json particularly, it just ate the world so it's easier to go along with it.
simonkagedal
The author seems to be using "markup language" as a concept basically synonymous with a configuration language, or something that is not a programming language. A markup language is a language used to "mark up" text with formatting and structure. This may sound like a terminology nitpick, but I would argue the reason why for example XML is not a great configuration language is that it was designed to be something else – a markup language.
bunderbunder
I think the author is probably aligning with "is" rather than "ought". So a language made this list if it IS being used as a configuration format, regardless of whether it OUGHT to be used as one.
Which is a way of deciding that makes sense given that I think the purpose of this article is "use my language instead". Getting lost in the weeds about each language's original design intent would bloat the article without meaningfully contributing to their thesis.
praptak
Jsonnet solves a different problem though.
Need to configure 5 services with hundreds of replicas in 7 data centers? Some values depend on the service, some on the data center and some on the combination thereof? Maybe also overrides for a bunch of problemstic machines?
And you also want a manageable config language which doesn't turn into a full blown Turing tar pit?
Then jsonnet is for you.
So it's not entirely fair to compare it in the "pleasant syntax" contest. It's like putting a Unimog into a ranking of city cars.
skrebbel
I don't like this article all that much but I do like the MAML format the author wrote this to promote. It seems like it’s everything that’s good about JSON, plus everything fixed for human writing, and nothing more.
Hats off, wish my package.json and build.yml were package.maml and build.maml.
hendry
What about bash? https://wiki.archlinux.org/title/PKGBUILD
sunrunner
No mention of The Configuration Complexity Clock [1] which I always think deserves a link, but credit to the author for actually keeping it slim and readable over (IMHO) most of the newer additions to the landscape which either declare themselves as 'obvious' and aren't or just add features such as Pkl's extends keyword, moving us further round the complexity clock.
Of course just adding multiline strings is the start of the rabbit hole, now you need to think about leading line breaks, trailing line breaks, intermediate line breaks, whitespace chomping, and- oh heavens I've reinvented YAML, I think I need to lie down.
[1] https://mikehadlow.blogspot.com/2012/05/configuration-comple...
Terr_
One kinda-exception I'd like to raise: Cases where you'd like to use the regular proper programming language from the very beginning, but there are trust issues, and there's no good/reliable sandboxing option.
For example, B2B stuff where every customer has their own idiosyncratic sets of rules for if-this-then-that, which change at a different cadence than your releases.
In those cases, it's less that configuration slowly becomes too complex and evolves into code, and more that code is wanted from the get-go but configuration is the compromise.
sunrunner
> every customer has their own idiosyncratic sets of rules for if-this-then-that
So Varnish Configuration Language? It's definitely an awkward case that doesn't seem to fit neatly into the landscape.
repsilat
I wonder if "the right solution" is a programming language that is fast, concise, trivially easy to run, and outputs some efficient binary format like protobuf.
Programming languages have comments and control flow, multiple popular implementations, and can have nice literals. Lack of Turing completeness is actually not a terribly useful feature if you trust the input (and you should probably just use protobufs or similar for untrusted inputs in that case.)
rdtsc
There is also .ini, it's simpler than toml, though has more inconsistent implementations and formats. But the '[[table]]' is just '[table]' and I like the '[table.subtable]' syntax better.
But since we're criticizing formats ;-) maml https://maml.dev is fairly good good.
* I like multiline blocks and comment style
* I do not like optional commas, either require them or not. I'd lean toward requiring them.
* Not sure about ordered object keys. How should languages represent that, a map/dict kind of a data structure won't work it would have to be an ordered dict/list of kvs etc. Two objects {"a":"x", "b":"y"} and {"b":"y", "a":"x"} will be different then. I get the idea, but I am leaning toward not liking it by the time I finished typing all that.
* I like booleans and null. Good for not having ons and offs those are just annoying.
0dayz
Personally I have embraced using sqlite as my configuration infrastructure, as the more I've used configuration formats, the more I've felt they are glorified databases.
Mikhail_Edoshin
A configuration language for what? What kind of configurations?
curious_curios
I've actually been getting a lot of mileage out of textproto: https://protobuf.dev/reference/protobuf/textformat-spec/
Well typed, simple syntax. Maps are annoying though.
bjackman
I agree on this in general. The awkward things here are that:
a) textprotos aren't really touted by the protobuf folks as a thing to use outside Google. I'm not 100% sure why this is.
b) inside Google, there's a perception that you shouldn't use textprotos for much other than hardcoding proto values inside the monorepo (where there aren't really schema-versioning concerns). I think this perception is misplaced, you just have to be aware that a given schema is used in textprotos. Which is usually an easy thing to be aware of. This is just because the schema-versioning concerns are different than with binary photos (e.g. field renames are now breaking).
c) IIRC most parsers unconditionally reject unknown fields. I think the reason for this is highlighted in the docs: you can't safely go from a textproto with an unknown field to a binary serialisation of that proto. IIRC there are some parsers that let you parse unknown fields anyway but then I think you're a bit more tied to a specific implementation than you'd like...
One strange but quite handy alternative is actually the JSON representation. You can use .proto files as a schema but then serialise the values to JSON as there's a canonical mapping. Then you get something that's human readable but with the type safety of protos. Although of course it's not really writable since... It's JSON.
throw0101c
What is the name of the style found in (e.g.) ISC BIND9:
* https://www.zytrax.com/books/dns/ch6/#master
* https://bind9.readthedocs.io/en/latest/manpages.html#named-c...
ISC-style? (E/A)BNF-ish?
Personally I like (a) the open/close braces for better stanza navigation, (b) all statements/lines ending with semicolon.
(Something similar was used in (now-EOL) ISC DCHPd, and they've moved to "extended JSON" for their new DHCP server, KEA.)
In the world of human-readable data formats (ie not programming languages), the best one I ever used was Jane Street's sexplib[1] s-expression format.
It was concise and expressive. There was a direct way to describe variants (types with multiple constructors), which is always awkward in JSON, but the format was still surprisingly low-noise for reading and editing by hand. I remember you could even use it as a lightweight markup format:
(The format leaves the interpretation of things like (em ...) up to you; you could use it as a slightly more verbose Markdown, but you could also use it to structure readable text with other sorts of metadata instead.)And, unlike certain other formats I won't name, it has comments!
It also helps that Emacs with Paredit makes editing s-expressions flow. The tool doesn't need to know anything about the sexplib format specifically; just relying on basic s-expression structure gives us fluid but simple structural editing.
I am constantly sad that nobody else uses this sort of format, and I have to deal with a mixture of JSON, YAML, TOML and other ad-hoc formats instead.
[1]: https://github.com/janestreet/sexplib