[angelzen]

Overreaction? Let's hypothetically consider yaml+, with the definition:

  yaml+ = yaml "\n" "."

* easy to wrap a yaml parser and create a yaml+ validating parser.

* 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.

[sa46]

- Define a new file format, yaml-plus.

- 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.

[angelzen]

Not really. Team X uses Java? Someone on the team takes 1 hour to create YamlPlus.java, submits to the monorepo. Now team X + all the other 100(0) teams that use Java have access to a yaml+ parser. Same with Golang, JS, Python, C++, cli check, presubmit check, and we are running out of supported languages.

The argument that no incremental change is ever possible because it has to update every related legacy usage is a recipe for organizational paralysis.