Hacker News Reader

Comment by devxpy | Hacker News Reader

Great! Another file format for me to learn. Why can't everyone use one of the standard file types, like YAML/JSON?

I really wish people wouldn't use JSON for configuration. The lack of comments and shortcomings in formatting abilities make it particularly ill-suited. { "_comment": "this is a comment" } is cringeworthy to. It's great for transport, but horrible for static file config.

YAML is good, but not to everyone's taste. I've been using it for a long time (as a ruby developer) but many people I know find it ugly.

I think Arc config looks much better than anything they could have come up with using JSON/YAML. Optimize configuration files for humans, not machines. If its simple enough to learn and be readable, more power to em.

If you want human, you can look at TOML

https://github.com/toml-lang/toml

Its the thing Pipfile uses.

The point is, don't invent file types!

It's interesting. can you have @js more than once? can you have @app more than once? pretty sure ಠ-ಠ is a valid app name, but ಠ_ಠ isn't. i also can't quite tell how to say map of maps. i'd guess it's

    @this-section-has-a-map
    hello-world
      name child-map
        ಠ-ಠ a
        ಠ_ಠ b

but it's hard to tell. Also, i'm not exactly a fan of { "_comment": "this is a comment" }, but i've run into several situations with yaml where i want to build a tool to rewrite a bunch at once, but since comments have no representation in the parse tree i have to do goofy vim macros to do my edits. since _comment is in the tree, i can add more keys without trashing the existing comments.

Hey, one of the .arc authors and maintainers here.

Only one of each section is what we designed for though the validations for that might be broken (and if so we can fix right away). Nesting is limited to one level. No need for more that we've seen yet.

I'm a proponent for JSON but agree that the lack of comments are one of the more annoying things I frequently run into.

edit--Especially when it comes to users editing config files. Imagine a new user trying to edit a web server/db/.bashrc file that didn't have comments to help out?

Rather than inline-comments I've always had separate documentation. This helps prevent trying to cram all the edge case caveats and everything into the configuration file.

inline comments are handy for pointing out "non standard" configuration settings for your enviroment. especially on production systems.

It aids in troubleshooting greatly to have inline comments point out "odd" settings in configuration without having to look at seperate (usually old) documentation.

Then use json5. Super weak excuse. Or use yaml or some other format and pipe it into some to-json converter.

Also, json has json schema which tools like VS Code support. They can autocomplete your config. Pretty promising over most other tooling.

But coming up with your own config has pretty much all the downsides. Yeah, you can invent some cuter syntax. But now your users can't even get syntax highlighting in their editor. Awful UX.

JSON5's support for unquoted keys seems like a misfeature. Not to mention that (by its nature) it has the same (lack of) support burden as any other new configuration format. If you're going to go through that frustration and incompatibility, why not pick something better suited to the job?

> JSON5's support for unquoted keys seems like a misfeature.

Seen plenty of JSON without quoted keys before that just seemed to work, so depends on parser.

https://serverless.com/ - uses yaml or JSON or js. This looks like an opportunity for the community to grow some more which is almost always a benefit. A new filetype isn't always the best, but it CAN be useful in some contexts, I haven't vetted if this is the right one.

Yup, serverless works quite well. have used it myself.

Albeit, I'm not fully sold on this whole fake-serverless architecture.

A major part of it is that AWS is arguably frustrating, since the docs are __clearly__ written by marketing people, not engineers. Every aspect feels non-dev friendly.

I would love to see something like Captain Duck Duck, so you can host your own serverless platfrom, sort-of a personalized AWS?

(Captain Duck Duck is a personalized Heroku)

Link - https://github.com/githubsaturn/captainduckduck

> Architect leverages Node and NPM to finally bring some structure and insight to the AWS Serverless landscape.

But this is the killer Node and NPM framework...

To summarize: a three line .arc file yields a 700+ CloudFormation YAML document. Let me know if you have any more questions!

This is just not true. The discussion is about the syntax (.arc vs yaml), not the information it contains.

it's precisely true; but I get your gist. if you enjoy writing that much cloudformation then by all means have a good time!

I don’t think you get my gist about syntax vs information. I can express the same data in a different format, in the same way that JSON and YAML can often be transformed into each other.

You are pulling a straw man by implying that requires much cloudformation, which is completely unrelated. Besides, CF is a good example of how you can use two different syntax to describe the same information.

> I don’t think you get my gist

if so, leading with "just not true" contributed to this (which seems like a non-sequitur if you're not saying the claim is false)

The format of a configuration file has no relation to the output of the program that parses it. Why are you being so obtuse about this? Your three-line arc file would be a three line YAML file. Stop doubling down on this nonsense.

exactly

Why can't everyone use plain simple shell syntax for setting values and then source the configuration file?

Reply on news.ycombinator.com