I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have
destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn’t.
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all
the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
Clarification: when speaking of json formatting I handle 2 distinct cases that make sense for me: inline objects and inline arrays (where all properties/ elements are on the same line) which make Configs more readable when the objects / arrays are small.
2023 (165 points, 221 comments) https://news.ycombinator.com/item?id=36018817
2020 (146 points, 160 comments) https://news.ycombinator.com/item?id=24436550
2018 (358 points, 195 comments) https://news.ycombinator.com/item?id=17513770
> Although it claims to be a human-friendly language, TOML constitutes a step back into something more robotic and primitive when compared to INI files and libconfini's approach.
INI files are a complete, utter mess to the point it's even hard to argue they exist as a specified format. TOML's value proposition is specifying a INI-like language.
The critique is an exercise in myopic nitpicking, and confuses specification with implementation. The doc even whines because strings and numbers are different types. Go figure. The whole document is a textbook example of "not even wrong'. A waste if time.
By the way, TOML is supported as the config language of tools such as Rust's Cargo and Cloudflare's Wrangler. It's funny how things actually work in the real world in spite of these documents.
I am not sure it isn’t a well-written parody of a rant.
I agree with his premise that TOML is not user friendly, but INI is not useful enough. CONL attempts to land in the gap