Here was my use case: We had an existing config system built around json that was typically machine written from human GUI manipulations. Our existing system

Here was my use case: We had an existing config system built around json that was typically machine written from human GUI manipulations. Our existing system could process json but not HOCON. HOCON after it parses config file(s) provides a tree that can be written out as json. I had to I start writing the configs out by hand instead of using the GUI. So I started refactoring my config as HOCON because it has some moderate boilerplate reduction and DRY helping features. Then I'd load those new configs with the HOCON library in Scala and have it spit out json which the existing system could then parse (in memory did have to write out files fortunately). I was in a Scala stack so using HOCON was a natural fit. I tried snake-yaml as well first but HOCON was easier for me to get up and I felt had a less wonky syntax. (I use yaml quite a bit for ansible so I am fairly used to it but even ansible extends yaml a bit to make it easier to write). Writing configs in json is a really big pain because: 1. No comments 2. No comments 3. "Having" "to" "quote" "all" "the" "keys" "and" "strings" "is" "painful" I understand that perhaps I could relax those rules in the json parser but then I am just a step away from HOCON which adds higher order stuff. IntelliJ had good HOCON support (ctrl+click to go to key / error highlighting) too so that helped. N.B. their yaml support is also good (via a plugin). Anyhow keep in mind the way I used HOCON was quite different from how I have seen it used by other devs in the space. Whereas they included it in their jars then let users override stuff at runtime. I was able to use some of those design goals to make a modular slightly higher order json config system where I could share common configs as importable overrideable libraries. Now if I had to have a system where humans and machines are "editing" the same file which was a case I had considered supporting for my system, I think I'd try to move the problem away from the same file space. And ask the question: Is there any way we can keep them out of the same files? Because that is probably easier than having the machine side keep track of comments in the parse tree and write them out when changing stuff. I'd try to sidestep by having my config system support importing files and merging them together and look more at how the directory.d pattern works in linux.