In a similar vein, JSON's lack of comments makes me marvel at how consistently JavaScript seems to choose the worse option. I'm oh so glad it found its way into config files
As a data/serialization format (the original intended use of JSON), I think no comments is the right choice, since adding comments introduces a bunch of questions about how comments ought to be parsed into a datastructure (or if they should be sent/(de)serialized at all). But for config files the lack of comments is the wrong choice, since typically you want to explain why things are set the way they are. The lack of ordering of entries also makes total sense for data/(de)serialization, but makes no sense for a config. I think the problem is people are lazy and just want to JSON.parse() everything, and used JSON in places it doesn't belong, like config files.
Many JS toolchains will take js files as config to alleviate this problem. Which is actually nice if you ever need dynamic configs, cause that means not using some forsaken DSL. It still evaluates to JSON in the end.
Not the person you’re replying to but you were clear in what you were describing.
It seems like they were thinking of some json parsers that’ll ignore just straight up anything after // before a new line in JSON (looking at you visual studio). So a .NET dev who has never touched anything but Visual Studio may make comments in the appsettings.json for a .NET project and it made all my command line parsers throw errors. Thanks Microsoft.