Goodbye Hjson
hjson.org
hjson.org
It's too bad I cannot suggest an alternative other than to say that I learned to live with YAML :|
You might like StrictYAML[1].
You're wrong that it's not used by anything important. It's integrated at Major Investment Bank and developers are shipping hjson files every day. They don't actually have a choice to configure and ship their services.
It's spreading slowly to more internal stuff as people realize they are better off with HJSON, rather than anything else. It will eventually reach the rest of the bulge bracket within a decade as people move around and pollinate the best stuff. HJSON could be running the global financial market by 2028 or 2038.
JSON by itself is definitely lacking in human friendliness.
HJSON and JSON5 were both solutions I liked. TOML is good too, and HCL is ok - but they don't quite serve as that nice drop in replacement that HJSON offered.
I can't agree with that assertion. As i see it, JSON is practically flawless wrt human friendliness. It's a self-documenting human-readable data interchange language that's even trivial to parse. A lot of people have plenty of ideas about what nice-to-have features they'd like to see but that's just YAML talk that only leads to YAML nowhere.
I guess I just don't see where this fills a gap.
You can fake it by having say, dot-delimited keys, but a lot of the complexity of config file formats come from the desire to support arbitrarily structured data when sometimes it's just as easy to fake it, not have it, or even use some templating.
Not exactly true (nor completely untrue). Look at your .gitconfig to see an example of how it can shoehorned in. Basically, it uses a .dot notation in a section header to distinguish levels.
I wrote an little module a few years back that copes with structure support: https://www.npmjs.com/package/jsinf#the-format
I agree, but the problem with ini is that it isn't a format in the sense that it hasn't been formally defined in a consensual way. Thus the monumental success of TOML as it fills the void that ini left unfilled for decades.
There are places with slightly relaxed JSON, like JSON + comments (e.g. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...). But it's often not well documented, and because these relaxations lack a name there's no commonly accepted set of relaxations.
But I guess we should just accept YAML, as it seems to be the standard-that-isn't-json.
I thought that the JSON way of implementing multiline strings was through an array of strings.
- One in go - https://github.com/google/go-jsonnet
- One in C++ - https://github.com/google/jsonnet
AFAIK, ksonnet is the primary user - https://ksonnet.io/ - which to any ex-googler be the more familiar way of dealing with the borg configs.
HJSon seems nice, as once in a while how to put a comment in JSON comes, and everyone starts bike-shedding their favourite solution, that leaves lots questions... of compatibility. For example, we tend to use "_comment": "", but I know that's bound to break somewhere, soon or later.
There is also https://json5.org/