because inin files have no or very limited support for nesting

there are also some issues with keys being all string by default making some things like linting harder and allowing more less standard ways to get something done, e.g. in json true is true in init files all of true, 1, yes, y and others might be true depending on the application (but then yaml no problem is worse)

also there is no clear single standard for init files

through this is where toml comes from it took the general layout ideas behind init files but give it a strict standard and strict string vs. bool vs. float types and a bit more nesting capabilities and fixes some string distance escape issues, etc

you might want to read this fine piece of propaganda https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

INI files are not specified anywhere, so it ends up being a implementation-defined free-for-all.

Also, YAML supports data structures that INI files don't.

I don't understand the hate that YAML gets. If you're not tasked with writing a parser, the data format just works as expected.

> I don't understand the hate that YAML gets

https://noyaml.com/ is a decent overview of exactly how shit it is.

But outside of that, using spaces for logic is extremely error prone if you go past 10-15 lines and 2-3 levels deep.

>https://noyaml.com/

I'm not sure this is the criticism you think it is. Wow, so you basically have to add quotes to get strings in some ambiguous situations?

Yeah sure you could probably improve YAML by getting rid of these weird pitfalls, but that is a minor improvement. The alternative isn't something like TOML, because YAML is optimized for hierarchical configuration. It's every vendor implementing a different syntax such as Hashicorp with their HCL [0].

[0] https://github.com/hashicorp/hcl

> https://noyaml.com/ is a decent overview of exactly how shit it is.

If that site lists all the complains that nitpickers managed to put together, it sounds like YAML is virtually perfect.

Also, to underline how silly and futile these nitpicking complains are, some YAML parsers already explicitly address silly things like the Norway problem.

This has literally never been a problem for me despite writing considerable amounts of YAML.

Frankly, this is a phantom benefit: the first thing people do in brackety-languages is define an indent standard. And it's not like a brackety language magically saves you from mis-nesting things if a bracket ends up misplaced.

just the No string is that it? Other than that I've never encoutered any other problem.

> 2-3 levels deep.

Same to python, all non-trivial code is like 4 level+ depth, big deal!

I normally write javascript and I switch to python easily from time to time. I cannot understand people who complain about spaces.

What about?

    NI: Nicaragua
    NL: Netherlands
    NO: Norway

or

    python: 3.2.3
    numpy: 2.1

or

    octal: 042

Tell me those are well defined or not confusing.

I don't know if it's yaml or jinja, but variations of https://mastodon.communick.com/@raphael/111059057995356737 keeps me wishing that we dropped all these formats and just adopted some type of lisp that could be embedded in all languages.

It's not type safe.

> It's not type safe.

I fail to see what leads you to believe this is a relevant point when discussing INI files as the alternative to YAML.

Yaml coerces values (the string "on" is coerced to bool true for example), with ini you do any conversion from strings yourself

> with ini you do any conversion from strings yourself

INI isn't specified, thus you cannot claim that the INI format does something a certain way.

The best shot at a specified INI file format might be TOML, and even that format is subjected to the same type of criticism.

So is JSON, and all mainstream config formats actually. However, that stopped being a problem with JSON schema, which, despite the name, works on yaml too.

>> It's not type safe.

> So is JSON

Blink. I beg your pardon, JSON is strongly typed per RFC 8259 standard:

> JSON can represent four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays).

The type system does not align well with any other type system out there (float/int ambiguity, no timestamps, etc.) but it's still better than any coercion.