I understand your points as precisely in the opposite direction to your conclusion.
According to this post, the INI approach says that the code that reads the value determines what type it should be. That approach means that you never get a problem where NO is a boolean when it should have been an enum, or a version number is a float when it should have been a string. You only get those problems when the type of a value is determined from the file without reference to the expected type, like in TOML.
>According to this post, the INI approach says that the code that reads the value determines what type it should be. That approach means that you never get a problem where NO is a boolean when it should have been an enum, or a version number is a float when it should have been a string
That's a simplistic view.
In practice, there soon wont be just one piece of code reading your files, or it will be shared elsewhere, and it will all depend on implicit semantics and documentation of the assumptions (if you're lucky to have it). Hilarity, chaos, and head scratching ensues.
Whereas with a format that enforces the types, every consumer with a parser for the format gets the same values (to the extended that it matters: a list doesn't suddenly become a string, but in some language it might be a vector and in another an array).
Configuration files usually are only read by one piece of code. Besides, the article is correct in that the type system from TOML is completely inadequate for fully parsing the files anyway, so it will necessarily depend on implicit agreement on the semantics from every reader.
IMO, configuration file formats should only ever have text as primitive type. Anything else should be defined in another layer. I completely agree with that part of the argument from the article.
Then the article goes to argue that the quotes are harmful... And no, if you have a whitespace sensitive language, you need a damn good representation for strings that won't allow for ambiguity to creep in. And INI is just horrible on this.
>Configuration files usually are only read by one piece of code.
Having a single source of truth and multiple services and scripts needing the same info means the same configuration file will get to be read by many pieces of code, even from different languages.
And that's without considering piecemeal migration of the same "one piece of code" running on different services to another language or a version two design, still needing to read the same file.
>IMO, configuration file formats should only ever have text as primitive type. Anything else should be defined in another layer. I completely agree with that part of the argument from the article.
I mean, that's not even wrong.
Except if you mean "they should not be binary". Then, sure.
Structured formats cannot natively represent every possible type. For example JSON might support very basic types, like integers and booleans, but not more complex types like date/time types. Formats like JSON only have an advantage when discussing built-in types. Because with JSON, if you say "this field is a boolean" then everyone knows its possible values, however, if you say "this field is a date" then who knows? The point the article makes is the format itself shouldn't dictate types and to let the application decide them - which it what happens anyway for types the format doesn't natively support. You need documentation either way.
According to this post, the INI approach says that the code that reads the value determines what type it should be. That approach means that you never get a problem where NO is a boolean when it should have been an enum, or a version number is a float when it should have been a string. You only get those problems when the type of a value is determined from the file without reference to the expected type, like in TOML.