Yeah, I noticed - that's mostly just because of the general flow of trends. XML was a hard swing in terms of complexity - it allowed you express everything, bu

Yeah, I noticed - that's mostly just because of the general flow of trends. XML was a hard swing in terms of complexity - it allowed you express everything, but did it in such a way that very few people would actually enjoy writing it. So it fell out of favor and folks moved to JSON for its simplicity. Then JSON proved to be somewhat too onerous because of several tiny annoyances (lack of comments, but also things like not allowing trailing commas in lists/dictionaries), so devs started trying out YML. YML quickly proved to have too many footguns because of the way its parser behaves, so it is now being abandoned in favor of TOML. Trends are a pendulum. They go back and forth, slightly changing each time they do. Complexity falls out of favor so we move to simplicity. Simplicity proves too simple so we go back to complexity, but slightly different than the old one. That too will fall out of favor and we go back to a slightly different kind of simplicity. Just how it goes. As for TOML - it's fine, I'd probably use it for a new project, but it's also undeniable that TOML in general feels a lot like supercharged INI. And that should in turn ask the question: why do we need that supercharged INI. Why should a config parser decide what primitives to return/what objects to construct them to? We can bolt schemas and other stuff on top of config parsers all we want, but why should that be the task of the parser? INI only deals in strings. In many ways, that make things a lot easier. Most static typed languages I've worked with tend to bolt getPrimitive() functions onto their config parsers for every type that throw an exception if it can't understand the type (which also makes the API extremely messy to read). Meanwhile most soft/duck-typed languages just throw you in the depths of it and give you whatever the fuck they parsed out of it. Usually you just end up manually type checking the data after. With INI, all you have is strings. It's simple, it's clean and it doesn't need to infer anything else (which also fits nicely with paradigms like "do one thing, and do it well").