Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
awesome-json-next
A Collection of What's Next for Awesome JSON (JavaScript Object Notation) for Structured (Meta) Data in Text - JSON5, HJSON, HanSON, TJSON, SON, CSON, USON, JSONX/JSON11 & Many More
-
-
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Seems you're missing my personal favorite, extensible data notation - EDN (https://github.com/edn-format/edn). Probably I'm a bit biased coming from Clojure as it's widely used there but haven't really found a format that comes close to EDN when it comes to succinctness and features.
Some of the neat features: Custom literals / tagged elements that can have their support added for them on runtime/compile time (dates can be represented, parsed and turned into proper dates in your language). Also being able to namespace data inside of it makes things a bit easier to manage without having to result to nesting or other hacks. Very human friendly, plus machine friendly.
Biggest drawback so far seems to be performance of parsing, although I'm not sure if that's actually about the format itself, or about the small adoption of the format and therefore not many parsers focusing on speed has been written.
For hand-writing I love jsonnet, which produces JSON, is much more convenient to write, and has some templating, functions etc. https://jsonnet.org/
You wouldn't serialize data structures to jsonnet though, you'd just generate JSON.
You can catch this with yamllint (https://github.com/adrienverge/yamllint):
% cat countries.yml
Not YAML by itself, but there are libraries that parse a YAML-like format that is typed. For example this one: https://hitchdev.com/strictyaml/. Technically, it is not compatible with the YAML spec.
Reminds me of the multiple YAML bugs that have plagued Kubernetes such as https://github.com/kubernetes/kubernetes/issues/82296
It is interesting how the standard of any language seems to diverge due to just the implementation from different parsers.
Cue also solves this problem. The "no" example is right on the front page: https://cuelang.org
I used it for configuration of a Go program recently and found it pleasant to work with. I hope the language is declared stable soon, because it's a good model.
You might look at JSON Next variants (if you remember - "classic" JSON is a subset of YAML), see https://github.com/json-next/awesome-json-next
my own little JSON Next entry / format is called JSON 1.1 or JSONX, that is, JSON with eXtensions, see https://json-next.github.io/
I prefer JSON over YAML because I spend more time confused and burned by the problems caused by it.
I understand that people don't like directly use JSON because it's not very friendly: no comments, no multi-line string, etc.
A great alternative IMHO is cson[0]. It's like JSON to JavaScript but for CoffeeScript (though nobody talks about it nowadays). It has indentation-based syntax, comments, and multiline string which usually don't need to escape. The advantage is it's close enough to JSON which is the canonical format that everybody can agree on nowadays. For YAML and TOML there are too many visual part-aways from JSON.
Or just create a JSON variant that enables comments and the backtick multiline string from JavaScript.
[0] https://github.com/bevry/cson
TOML also has a few restrictions, such as not supporting mixed-type arrays like [1, "hello", true], or arrays at the root of the data. JSON can represent any TOML value (as far as I know), but TOML cannot represent any JSON value.
At my company we use YAML a lot for table-driven tests (e.g. [1]), and this not only means lots of nested arrays, but also having to represent pure data (i.e. the expected output of a test), which requires a format that supports encoding arbitrary data structures.
[1] https://github.com/sanity-io/groq-test-suite/
Still early, but here's my baby I hope can improve things:
website with grammar spec: https://tree-annotation.org/
prototype of a JSON/YAML alternative for JS: https://github.com/tree-annotation/tao-data-js
same thing, even less finished for C#: https://github.com/tree-annotation/tao-data-csharp
working on it constantly, more to come soon
Still early, but here's my baby I hope can improve things:
website with grammar spec: https://tree-annotation.org/
prototype of a JSON/YAML alternative for JS: https://github.com/tree-annotation/tao-data-js
same thing, even less finished for C#: https://github.com/tree-annotation/tao-data-csharp
working on it constantly, more to come soon
If you want automatic built-in string validation, one option that seems particularly interesting is to use a variant of Lua patterns, which are weaker and easier to understand than regular expressions, but still provide a significant degree of "sanity" for something like an email. The original version works on bytes and not runes, but you could simply write a parser that works on runes instead, and the pattern-matching code is just 400 old and battle-tested lines of C89.
Lua patterns have also shown up in other places, such as BSD's httpd, and an implementation for Rust:
https://www.gsp.com/cgi-bin/man.cgi?section=7&topic=PATTERNS
https://github.com/stevedonovan/lua-patterns
http://lua-users.org/wiki/PatternsTutorial
