Hacker News new | past | comments | ask | show | jobs | submit login

Acornfiles? I feel like when you introduce a new config format, a common expectation will be having a prominent "Why Acornfiles?" page where you explain why this new format is necessary. Without it, I personally groan and look away. With it, you are still wasting time explaining your config format, time that should be spent explaining the benefits of the larger system you're offering.



I'm not sure what existing off-the-shelf thing you would use instead. There is some overlap with things like docker-compose, serverless.yml, helm charts, etc. But each of those things is targeting a different use case and/or level of abstraction.

So if acorn is also a different use case or level of abstraction, it can't really reuse those formats. Their set of 8 top level structures[1] seems reasonable at first glance to me.

[1] args, profiles, containers, volumes, jobs, acorns, secrets, localData


I think the problem here is that it introduces a new syntax, not the configuration options itself.

Why not just use yaml as a syntax? At the top of the document they already say it’s very similar anyway, I don’t see what this does that can’t be done with yaml?

http://docs.acorn.io/authoring/overview


Ah yep. I didn't look carefully, and just assumed it was json, but looking again it's not.


What do you think is a suitable alternative to custom yaml formats?


Inventing new configuration languages to get away from yaml is a blisteringly terrible plan.

Yaml doesnt spark joy for me, but it's ok & there's lots of good tools & libraries to support it. Json & toml are basically the only other modestly well supported options out there.

This looks like a Yet Another Next Generation (YANG) variant. At least just use YANG. Even though it's vastly less supported.

For real, the amount of griping about YAML is unbelievable. It's not great but so what. It does the job. What people really are griping about usually is how much configuration/state is required. Where the spaces go, whether there's parenthesis or not is so far down the list of important factors. Metric miles behind "are there good tools & libraries?," for one.


You can use parenthesis with YAML though. It’s just not a common idiom.


Why is a custom format needed? Why not just use JSON or YAML?


That's totally valid! I don't have an opinion either way. I've heard people complain about yaml before and now seeing a strong reaction to another custom format I was curious to see what people would propose.

It would seem however from the responses I've been getting, that though YAML can be difficult or messy it's still better than another custom format.


I think HCL is very nice. Easy to read and write, has clear types, has basic functions (arithmetic, string manipulation, etc) with the ability to extend with custom functions as well. It can also be easily converted to JSON, which is a pretty cool way of adapting for machine manipulation.


Toml

JSON if you hate comments


for me, comment is a must for configuration format.


It's JSON with some syntactical sugar. Is that really so bad?


Yes. There are enough formats out there.


In software (unlike many (all?) other fields) there is enough of a lot of things out there; web frameworks, programming languages, crms, content management systems; the list goes on. People feel a flaw of sorts and roll their own. Most won’t get traction and will end up dead on GitHub (hopefully forever though; hopefully archive.org does/will clone all public repos).


Exactly this. I groan every time there’s a new yaml config format to learn, develop for and support. It feels like:

https://xkcd.com/927/


What would you suggest as an alternative? Legitimately curious what people think here.



YAML or JSON, mainly just any format that already exist. I don’t understand why a new syntax is required, especially when the ecosystem they operate in (k8s) is already dominated by YAML.


Just use the Deployment YAMLs we already have.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: