5 ms·
There are many issues with both formats: - JSON has no comments - YAML nesting tends to get deep which makes creating bugs very easy - Both are become hard to
by brianleroux 8y ago
There are many issues with both formats:
- 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.
- deleted 8y ago[deleted]
- devxpy 8y ago> The equiv CloudFormation YAML is 700 lines Accepted, but that's not the topic of debate. The issue here is that you can write the example you gave in YAML like this app: hi html: get / And it could still generate the same result. But this way people can write the config in a more familiar syntax. Hope I explained my point correctly. This is just a matter of UX/ API, not how it works. If you somehow felt that I disrespected your work, forgive me.
- sirbrows 8y agoI agree. And isn't that exactly the solution the Serverless framework implemented?
- devxpy 8y agoI am not sure, but serverless requires more config and tweaking as compared to arhitect. In contrast, serverless is a more mature and flexible platform.
- sirbrows 8y agoIt was more of a rhetorical question, Serverless definitely uses .yml https://serverless.com/framework/docs/providers/aws/guide/serverless.yml/ https://serverless.com/framework/docs/providers/aws/guide/se... Obviously that's a verbose example and there are defaults for most everything AFAIK. Anyway, Architect seems cool too! Always down for more options and competition!
- jacques_chester 8y agoYAML 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. [0] https://jsonnet.org/ https://jsonnet.org/ [1] https://github.com/enaml-ops/enaml https://github.com/enaml-ops/enaml
- xellisx 8y agoIIRC JSON 5 has comments and other 'fixes'. Also, '.arc' takes me back to the 80s and bbsing.