| ▲ | verdverm 7 hours ago |
| Yaml is my #1 failure in devops. That so many have resigned themselves to this limit and no longer seek to improve, it's disappointing. Our job is to make things run better and easier, yet so many won't recognize the biggest pains in their own work. Seriously, is text templating an invisibly scoped language really where you think the field has reached maturity? |
|
| ▲ | firesteelrain 7 hours ago | parent | next [-] |
| JSON so much easier in my experience and less prone to error |
| |
| ▲ | verdverm 7 hours ago | parent [-] | | JSON does not have comments, no JSON5 is not the answer either Think bigger, it's not something you are using today. The next config language should have schemas built in and support for modules/imports so we can do sharing/caring. It should look and feel like config languages and interoperate with all of those that we currently use. It will be a single configuration fabric across the SDLC. This exists today for you to try, with CUE I've been cooking up something the last few weeks for those interested, CUE + Dagger https://github.com/hofstadter-io/hof/tree/_next/examples/env | | |
| ▲ | throwaway7783 6 hours ago | parent | next [-] | | Like XML? :) | |
| ▲ | lijok 7 hours ago | parent | prev | next [-] | | Like Python? | | | |
| ▲ | firesteelrain 7 hours ago | parent | prev [-] | | I genuinely despise the identing requirements of YAML. For comments, I use a _comment field for my custom JSON reading apps | | |
| ▲ | orev 4 hours ago | parent | next [-] | | I dislike the idea of _comment because it’s something that is parsed and becomes part of the data structure in memory. Comments should be ignored and not parsed. | |
| ▲ | verdverm 6 hours ago | parent | prev [-] | | yeah, this is what I'm talking about, innovation has stopped and we do dirty hacks like `imports: [...]` in yaml and `_comment` in json How are people not embarrassed by this complete lack of quality in their work? | | |
| ▲ | firesteelrain 6 hours ago | parent [-] | | I don’t think we need anything formal resembling XML like JSON. It was originally meant for over the wire payloads and people like myself use it for more than that | | |
| ▲ | verdverm 6 hours ago | parent [-] | | You're still thinking "good enough". I'm advocating for the "we can do so much better" attitude The current popular config choices cause a lot of extra work, bugs, and effort. Is improving the status quo not a worthy goal anymore? Are we at a point in history throwing our hands up and saying meh, I deal with this... is basically where people are today? (I'm somewhat a believer of this based on anecdata and vibes) | | |
| ▲ | firesteelrain 3 hours ago | parent [-] | | The uncomfortable reality is that config formats don’t win by being best. They win by being: 1. already installed everywhere, 2. easy to parse in every language, 3. supported by editors/linters/CI tools, 4. stable enough that vendors bet on them. |
|
|
|
|
|
|
|
| ▲ | dissent 6 hours ago | parent | prev [-] |
| Write it in a higher level language and generate the YAML from that. See the YAML as a wire protocol, not something you author things in. |
| |
| ▲ | verdverm 5 hours ago | parent [-] | | exactly, why interop with everything that exists today is important however, you don't want config being turing complete, that creates a host of other problems at a layer you don't want them | | |
| ▲ | dissent 5 hours ago | parent [-] | | I know what you mean, but there seems to be some kind of misplaced fear about this which has led us down the garden path of unmaintainable config (or even trying to jinja template it!) If your config is turing complete and consumed as-is, then without a lot of discipline you can dig yourself into a hole, sure. If you're producing YAML that is not turing complete, that constraint means you have to code in a way that produces deterministic output. It's actually very safe, and YAML maps 1:1 to types in something like Python. My favourite go-to example is for AWS Cloudformation: https://github.com/cloudtools/troposphere |
|
|
