AWS – The YAML Way
github.com
github.com
I sort of remember it was a contributing factor to a significant outage. A YAML config file was truncated and given partial configuration and otherwise falling back to default config, it put a system into a bad state.
YAML was banned by some teams (and discouraged in most teams), because you can't detect a truncated file, like you can with XML or JSON.
yaml+ = yaml "\n" "."
* easy to create a simple script to validate the end-of-file dot line.
* easy to create a presubmit check to validate yaml+
* easy for an editor to syntax check the end-of-file dot line.
Assuming there are other redeeming qualities of YAML, the truncated YAML problem can be solved with minimal effort.
- Create a parser for the new yaml-plus format across all supported languages.
- Migrate all build processes to handle yaml-plus with the new parser. In a large-org, it's likely impossible to track down all the usages of YAML. Someone will have a bash script that hasn't been touched for 10 years that implements an adhoc YAML parser.
- Modify the YAML mode for all supported editors to support the new syntax.
This doesn't sound like minimal effort. Mandating that all new configs must be JSON (or similar, newer alternative like cue) is way easier since JSON already exists.
The argument that no incremental change is ever possible because it has to update every related legacy usage is a recipe for organizational paralysis.