- JSON has no comments
- YAML nesting tends to get deep which makes creating bugs very easy
- Both are become hard to read / edit in larger files
The primary issue is translating the intent into a machine syntax. The format we landed focused on minimalism to communicate intent.
The the file format is the least interesting thing about .arc but one of the most distinctive. An .arc file VERY QUICKLY communicates the project intent.
An example:
```
@app
hi
@html
get /
```
The equiv CloudFormation YAML is 700 lines. You'd have no idea what that project does without digging into the code. The .arc by contrast is extremely easy to both read and author. As the app grows it becomes very clear the project intent and were to find things.
We certainly could have created a new YAML thing but many projects already do that … and I'll let their work speak for itself.
I am not sure, but serverless requires more config and tweaking as compared to arhitect.
In contrast, serverless is a more mature and flexible platform.
YAML works pretty well for the 80% case, I think. I work at Pivotal -- we use YAML so widely in our designs that a few years ago there was a swag t-shirt with the title "Enterprise YAML Architect" printed.
YAML's shortcomings can be addressed a number of ways. The most recent trends I've seen are:
1. Simplify the YAML itself.
This usually means introducing higher-order features that make long, repetitive blocks irrelevant. An example is BOSH v2, which introduced a number of features (Eg. BOSH links) that pushed repetitive scutwork into the tool, away from the YAML manifests.
A variant of this is to use more advanced YAMLisms to make your YAML files more concise. Anchors make a big difference. I've seen this be very useful in large Concourse pipelines.
2. Use something that renders down to YAML.
For example, Jsonnet[0] or Enaml[1]. Some folks will use templating languages for this purpose (erb, mustache etc).
Templating is a last resort, in my view, because it's hard to see what the output will be without rendering it. Plus most tools format nested syntaxes poorly.
On the upside, use of a full templating engine introduces opportunities for multi-file DRYing. But that itself should be a smell that the configured tool is missing some feature or capability.
3. Use a different format.
TOML appears to be the most popular alternative to YAML and JSON. Most recently I have seen the joint Heroku-Pivotal effort on Buildpacks v3 adopting TOML over YAML or JSON.
- JSON has no comments - YAML nesting tends to get deep which makes creating bugs very easy - Both are become hard to read / edit in larger files
The primary issue is translating the intent into a machine syntax. The format we landed focused on minimalism to communicate intent.
The the file format is the least interesting thing about .arc but one of the most distinctive. An .arc file VERY QUICKLY communicates the project intent.
An example:
``` @app hi
@html get / ```
The equiv CloudFormation YAML is 700 lines. You'd have no idea what that project does without digging into the code. The .arc by contrast is extremely easy to both read and author. As the app grows it becomes very clear the project intent and were to find things.
We certainly could have created a new YAML thing but many projects already do that … and I'll let their work speak for itself.