Live data from Hacker News

YAML and Configuration Files

utcc.utoronto.ca

41–50 of 96 posts

Re: YAML and Configuration Files

#41
post #7

I think I get what the article is saying. I don't think they expressed it very well. Here's a concrete example of what I think they're complaining about. From a Kubernetes Deployment manifest: - name: DATABASE_URL valueFrom: secretKeyRef: name: db-conn key: uri That valueFrom.secretKeyRef.{name, key} structure is an "exploded AST" — something that in any programming language, you'd be chastised for writing out as a s…

What do you mean by “exploded AST”? What’s a “structural-initialization literal”?

Re: YAML and Configuration Files

#42
post #30
post #17

Earlier quoted context omitted.

yaml (and json) gives configuration files much-needed hierarchy and structure, which is unbounded (within reason), not limited syntactically or inherently like simpler configuration formats including toml. yaml adds to that comments and a pleasant readable layout, even if it requires a little bit more from the editor to make it pretty. With that, I don't think yaml has much competition.

Toml has unlimited nesting as well. There are also many formats that are "better json" that have comments, multiline strings, trailing commas etc. Such as hjson, json5 (and variants such as json6, jsonX, etc.) and hocon. As well as more sophisticated languages like jsonnet, dhal, and cue. Many of these can be "compiled" to JSON. There is plenty of competition, but for some reason, YAML seems to be the most popular.

TOML gets very weird as soon as you have more than one level of nesting.

Re: YAML and Configuration Files

#43
How about not using configuration files in the first place? Instead expose a library in some programming language (preferably typed) to assist with writing config, then serialize the output in whatever format is easier to parse.

Re: YAML and Configuration Files

#45
post #3

After resisting it for many years I've finally settled on YAML as my default configuration format. I need a way of expressing the core data types of JSON (key/value mappings aka "objects", arrays, strings, integers, floating points and booleans) - plus comments, and multi-line strings that insulate me from complex escaping rules. YAML does that. It's not perfect, but it's good enough. And in Python I can use yaml.saf…

YAML seems to be one of the most polarizing things in the software industry. I'm personally a big fan of it, though I agree with the author that it becomes a pain once you start trying to use it like a DSL or templating language. I use it in pretty much every project, but I've worked with people who've said they hate it with a burning passion. And it's kind of a trope to see anti-YAML manifestos on HN and /r/programm…

> I'm personally a big fan of it, though I agree with the author that it becomes a pain once you start trying to use it like a DSL or templating language

If only the people behind Ansible agreed with this. Jinja+YAML templating is just utterly terrible.

Re: YAML and Configuration Files

#46
post #45

Earlier quoted context omitted.

YAML seems to be one of the most polarizing things in the software industry. I'm personally a big fan of it, though I agree with the author that it becomes a pain once you start trying to use it like a DSL or templating language. I use it in pretty much every project, but I've worked with people who've said they hate it with a burning passion. And it's kind of a trope to see anti-YAML manifestos on HN and /r/programm…

> I'm personally a big fan of it, though I agree with the author that it becomes a pain once you start trying to use it like a DSL or templating language If only the people behind Ansible agreed with this. Jinja+YAML templating is just utterly terrible.

Yeah, I completely get the widespread hatred of YAML due to things like that. It regularly gets abused to extreme lengths. But it also regularly gets used for relatively flat, straightforward, easily maintainable config/data files.

Re: YAML and Configuration Files

#47
post #7

I think I get what the article is saying. I don't think they expressed it very well. Here's a concrete example of what I think they're complaining about. From a Kubernetes Deployment manifest: - name: DATABASE_URL valueFrom: secretKeyRef: name: db-conn key: uri That valueFrom.secretKeyRef.{name, key} structure is an "exploded AST" — something that in any programming language, you'd be chastised for writing out as a s…

I guess the Elixir "custom sigil" is a generalized version of the Ruby or Perl special quoting styles for things like regexes or shell commands?

There are at least a couple of prominent versions of that: a great dynamic language version is JavaScript template literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...>; or in the static language world there's C++ user-defined literals https://en.cppreference.com/w/cpp/language/user_literal> (tho if I remember correctly they are horrible for strings unless you are using a recent version of C++)

Re: YAML and Configuration Files

#48
post #33
post #25

> YAML isn't a configuration language or a configuration language format, it's a serialization format I think YAML is even worse as a serialization format than a configuration format. It has too many ambiguities, implementations are too inconsistent, and many implementations are insecure by default with untrusted input. > Using a good custom designed configuration file format instead of trying to shove things through…

> I think YAML is even worse as a serialization format than a configuration format. This. I find YAML to be the least offensive option for configuration and one of the worst for serialization. I might be misinformed, but I find it absurd that in 2021 we still don't have a default, universally available tool that supports the basic table stakes without headache: 1. core data types (number, string, etc) 2. lists, maps,…

My JSON parser ( github.com/nanoscopic/ujsonin ) has these things:

0. Looks essentially the same as JSON

1. Core data types, and customizable data types can be added easily.

2. Arrays, Objects, and arbitrary nesting.

3. Comments ( both /* */ and // format )

4. Multiline strings ( by default; carriage returns are no problem within strings )

5. It is JSON with relaxed restrictions and slight addition for actual named types.

6. I've written C, Perl, and Golang implementations so far.

Re: YAML and Configuration Files

#49
post #39

Earlier quoted context omitted.

YAML seems to be one of the most polarizing things in the software industry. I'm personally a big fan of it, though I agree with the author that it becomes a pain once you start trying to use it like a DSL or templating language. I use it in pretty much every project, but I've worked with people who've said they hate it with a burning passion. And it's kind of a trope to see anti-YAML manifestos on HN and /r/programm…

> it becomes a pain once you start trying to use it like a DSL or templating language. I like YAML and use it a lot. But I'd argue the fact that it even allows/encourages you to do such things with it is a design flaw that ultimately has kept it from Do One Thing Well.

I do think some of the more "advanced" features are definitely a mistake. StrictYAML (https://github.com/crdoconnor/strictyaml) is a limited, much saner subset of YAML that I wish people would use more: https://hitchdev.com/strictyaml/features-removed/

No coercion of y/n/yes/no/on/off to booleans (these were also removed in the official YAML 1.2 spec, thankfully), no direct object representations, no anchors or references, etc.

Re: YAML and Configuration Files

#50
post #33

Earlier quoted context omitted.

> I think YAML is even worse as a serialization format than a configuration format. This. I find YAML to be the least offensive option for configuration and one of the worst for serialization. I might be misinformed, but I find it absurd that in 2021 we still don't have a default, universally available tool that supports the basic table stakes without headache: 1. core data types (number, string, etc) 2. lists, maps,…

It's a real shame JSON doesn't have 3 and 4, because it would be so easy and it's otherwise pretty much perfect imo. No ambiguity, every value type can be identified by its first character, clean and reasonably minimal syntax.

well there are json alternatives which fit this bill, such as HJSON.

https://hjson.github.io/

might not be as "common" but it has good implementations for many languages.

Post reply on HN