[brianleroux]

Author here: we did? Pretty well documented issues w JSON and YAML (coming from CloudFormation perspective). Both have problems (that are unique to each) so we created a format for solving that.

If you like JSON and YAML and don't mind those issues you are well served by existing solutions. Cheers!

[optimuspaul]

What problems did you solve and how were they solved with your new format? I'm neutral in this argument at this point, so I'd like to hear your justifications. Thanks!

[brianleroux]

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.

[devxpy]

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

I agree. And isn't that exactly the solution the Serverless framework implemented?

[devxpy]

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.

[sirbrows]

It was more of a rhetorical question, Serverless definitely uses .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]

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.

[0] https://jsonnet.org/

[1] https://github.com/enaml-ops/enaml

[xellisx]

IIRC JSON 5 has comments and other 'fixes'. Also, '.arc' takes me back to the 80s and bbsing.

[shakna]

Your arc format feels a lot like an INI-format, but with one or two teaks here and there.

Is it inherently better in a way I'm not seeing?

Would arc be suitable enough for a new project to adopt?

[brianleroux]

I'd like to leave the format discussion behind. Its the least interesting part and you rarely interact with it. I'll add YAML and JSON support so ppl can judge for themselves on merit against options that have tradeoffs.

Its absolutely suitable today. We have it in production in several apps. begin.com and arc.codes itself are two examples that have seen non-trivial traffic.