15 ms·

To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose.

To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel (https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants)? And people are actually using this in production software? Then when you add templating it’s no longer readable and concise anyways. So, why? In JSON, you can add templating super easily by turning it into regular JavaScript: use global variables, functions and the like. I don’t understand how anyone could prefer YAML with an ugly templating DSL over that. And if you really care about conciseness, there’s TOML. Are there any advantages of YAML over TOML?

chx 3y ago
> Are there any serious advantages of YAML over TOML? Probably not but you forget YAML came out in 2001 where TOML came out in 2013. Neither are spring chickens but inertia is a hell of a thing. For example, Symfony supports YAML, XML and PHP definitions -- but not TOML. Symfony v2 simply predates TOML and they never got around to ditch YAML for TOML because it's not worth the bothering.
- bayindirh 3y ago
  TOML is just an .ini file plus some syntactic and computing sugar. I can argue that TOML is actually way older than it is.
  - chx 3y ago
    1. I am unaware of a standardized .ini format 2. The native types in TOML are useful.
    - bayindirh 3y ago
      This is an .ini: [section] option=value it the way you want it. ; And these are comments. That's all. I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things. I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them. It's same for INI. You can have "native types" in .ini as well. The difference is you'll be handling them explicitly yourself, and you should do that in defensive programming anway. A config file is a stream of input to your code, and if you don't guard it yourself, you agree what that entails.
      - lpointal 3y ago
        > I don't think even though TOML has some official spec Read it on https://toml.io/ https://toml.io/ (Full spec on upper-right… with its evolutions up to final 1.00 version).
        bayindirh 3y ago
        Oh sorry, I missed a comma. It should read: "I don't think, even though TOML has some official spec, ..." Fixed the comment too. I know TOML has an official spec.
      - Brian_K_White 3y ago
        Zomg how did you magically read my brain to produce a perfect example of what I was thinking even though there is no IEEE spec? It's unpossible!
        bayindirh 3y ago
        I used Windows 3.1 and 3.11. That's all what I'll say.
      - arp242 3y ago
        > I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them. Overall it's not that bad, see e.g. https://arp242.github.io/toml-test-matrix/ https://arp242.github.io/toml-test-matrix/ If you look at the failure details then most of them are either minor issues about where things like escape characters are/aren't allowed, or about overriding existing tables (previously the spec was ambiguous on that, and I expect that will clear up over time). Note that overview is not entirely fair because it uses the latest (unreleased) version of toml-test where I added quite a few tests. These kind of imperfections in implementations are of course true for any language, see e.g. YAML: https://matrix.yaml.info https://matrix.yaml.info – I have no reason to believe it's worse in TOML vs. YAML, XML, JSON, or anywhere else. If anything, it's probably a bit better because it's fairly simple and has a pretty decent test suite.
lucideer 3y ago
> I don’t understand why people are still using it It's a good comaparator, there are indeed a lot of similarities, but I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. It's more like Python than Coffeescript really: it's not just about simplicity & brevity, it's about terminators. Whitespace-dependent languages are often a pain to format / parse / read in many ways - Python has survived this by the skin of its teeth by being extremely strict about indentation, both in terms of the parser & also community convention. YAML hasn't had this - it remains a mess. However, both have that very attractive property of not requiring terminators, which can't really be understated. > if you really care about conciseness, there’s TOML. Are there any serious advantages of YAML over TOML? TOML's got some good properties but its handling of structures with a depth > 1 is far from concise, and pretty terrible if I'm honest.
- mjevans 3y ago
  TOML's sections remind me of the directory part of a filename and keys files. For the content that belongs in a typical configuration file this or the INI style roots are probably the most human approachable formats. For anything more complex maybe a database (such as SQLite?) is preferable past application bootstrap?
- fsniper 3y ago
  Reading yaml has the enjoyment of reading a love letter where else json has the deterimental feeling of a solicitor email. For writing, yaml is like putting out the draft, you only focus on the meaning not care for else or the form, but for json it is like finishing up your thesis with hard defined structure.
- anoopelias 3y ago
  > why anyone ever used Coffeescript CoffeeScript was the front runner for 'Compile to JavaScript' technology. It was the first time we could write some sane frontend code. Of course things like TypeScript came along and now we cannot unsee what we have already seen.
- jeroenhd 3y ago
  > I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. When Coffeescript was invented, it was an advancement on top of the awful Javascript standards at the time. It never went anywhere because Javascript caught up, but Coffeescript had a good reason for existing. Today, Coffeescript is a remnant of old frontends that nobody has bothered transpiling into Javascript yet, but back in the day it was a promising new development.
bencelaszlo 3y ago
> Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants)? Norway is also "False".
- foldr 3y ago
  Or more precisely, its country code 'NO' is false. I don't think there are any YAML parsers that parse the literal string 'Norway' as false.
  - julian_t 3y ago
    Maybe one written by a Geordie?
  - Exuma 3y ago
    It’s very obvious that’s what he means.
    - gremlinunderway 3y ago
      shrug it wasnt obvious to me. I'm glad someone explained.
    - afavour 3y ago
      It wasn’t obvious to me. I read it as the literal string “Norway” being parsed as false, which didn’t sound believable but I didn’t make the connection to NO at all.
  - sgarland 3y ago
    Be the change you wish to see in the world.
    - andybak 3y ago
      I would support a move for YAML to standardize on both "NO" and "Norway" evaluating to false. It seems an obvious win for consistency.
bayindirh 3y ago
People balk at XML, but its verbosity plus DTD allows it to pull tricks which you can't do on other things. Well everything has its place, but XML is I think very well suited where you need to serialize complex things to a readable file, and verify it while being it's written and read back.
- mcculley 3y ago
  Indeed. I get a lot of value out of my strongly typed XML documents. I generally have code that validates them during writing and after reading. Those who don’t understand XML end up learning why it is verbose when they eventually add all of the features they need to whatever half-baked format they are using.
  - robertlagrant 3y ago
    Agreed. XML is clunky, no doubt, but it's partly that the tools were just clunky. Having said that, I do like that you can flip between YAML and JSON. If we could do that with XML (attributes vs sub-elements a problem here) it would be much more useful I think.
  - delta_p_delta_x 3y ago
    The 'XML is verbose' argument is exactly analogous to the 'static typing is verbose' argument. JSON is decent, but it quickly breaks down if you want to have any sort of static sanitisation on input data, and the weird `"$schema"` attribute is quite strange. YAML makes no sense whatsoever to me. XML is by far the most bulletproof human-readable serialisation-deserialisation language there is.
    - acdha 3y ago
      > The 'XML is verbose' argument is exactly analogous to the 'static typing is verbose' argument. It’s two things: the static typing analog is definitely there but I’d extend the comparison to something like the J2EE framework fetish & user-hostile tools, too. There were so many cases where understanding an XML document required understanding a dozen semi-documented “standards” and since few of the tools actually had competent implementations you were often forced to write long-form namespace references in things like selectors or repeat the same code. I worked with multiple people who were pretty gung ho about static typing everything but the constant friction of that self-inflicted toil wore over time. I sometimes wonder whether something more in the Rust spirit where the tools are smart enough not to waste your time might be more successful.
account-5 3y ago
Personally I prefer INI over nearly all configuration formats. https://github.com/madmurphy/libconfini/wiki/An-INI-critique-of-TOML https://github.com/madmurphy/libconfini/wiki/An-INI-critique...
- youerbt 3y ago
  I have seen this post on HN before and I wasn't received very well AFAIR. But I can't help agreeing with its main point: so much complexity to support a few basic data types that are not sufficient for anything complex anyway.
  - AndyKluger 3y ago
    If you haven't checked it out, NestedText is a great format that offers no handling of types beyond string/list/dict, leaving all that to the application reading in the values. No character needs escaping.
    - youerbt 3y ago
      Thanks, that might be just what I'm looking for!
LudwigNagasena 3y ago
Well, you can replace YAML with JSON and JS templating without changing the parser. So I guess that’s an advantage over TOML?
__jonas 3y ago
In general I am always confused that it lets you use strings unquoted, which is what allows for all these issues with ambiguity of the interpreted data type, Norway problem and all that. It also just looks odd to me, I don't see why it's necessary to allow this.
- hombre_fatal 3y ago
  It’s great for end users who don’t understand what a string is or don’t have to play the game of finding the hanging single quote when they write the file by hand in a textarea. On the opposite end of UX, there’s hand written JSON which is just too meticulous in some scenarios when people are writing config without editor support.
  - coffeebeqn 3y ago
    That’s probably a good thing for end users but if it’s running on something that affects the live service I’d rather not have people edit the config who don’t know what a string is
  - Dylan16807 3y ago
    Dealing with inline quotes is annoying, but if you care about users writing things by hand, and especially in a textarea, you should not be using a format that depends on indentation.
- afavour 3y ago
  It’s because YAML is designed first for readability.
torginus 3y ago
Dunno, to me YAML is the python of markup languages. YAML is decent at handling things like nesting and arrays, while TOML sucks at it. I don't dislike YAML that much. That being said, we knew since the dawn of C macros that templating languages which are not aware of syntax, are AWFUL. Likewise, writing Helm charts (the place I encountered YAML templating) is just horrible, but would be so much nicer is templates respected the YAML syntax tree and expanded at the right subnode, instead of being a text replace botch-jobs.
- wkat4242 3y ago
  The biggest issue I have with Yaml is that they forbid tabs. Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels. And forbidding it makes a one-keystroke action a two or four one. I really don't understand the python/Yaml hate for tabs, and as a result I don't really use either.
  - torginus 3y ago
    Like with Python, any competent text editor will take care of this for you, I've never encountered this issue before.
  - tvink 3y ago
    https://lists.gnu.org/archive/html/emacs-devel/2016-12/msg01000.html https://lists.gnu.org/archive/html/emacs-devel/2016-12/msg01...
    - bayindirh 3y ago
      This e-mail enters to my "favorite quotes from internet" list directly from the top.
      - bqmjjx0kac 3y ago
        It is a funny quip, but I wish they'd consider the reformatting. I find using an autoformatter reduces cognitive load while reading and writing.
brobdingnagians 3y ago
Having on and no both be Boolean literals, but of opposite values sounds like a horrible decision, a typo doesn't result in a syntax error, but instead in a completely wrong semantic misconfiguration.
- BenjiWiebe 3y ago
  1 vs 0 is another typo of Boolean values with opposite meanings, in quite a few languages.
  - naniwaduni 3y ago
    Worse, the ability to typo 9 in some languages for 0 and flip your boolean when it should be a type error just seems like a misdesign.
    - smaudet 3y ago
      Lets hear it for true/false, and triply enforced booleans (variables represented by three or more memory locations https://en.wikipedia.org/wiki/Triple_modular_redundancy https://en.wikipedia.org/wiki/Triple_modular_redundancy) !
cmiller1 3y ago
> Are there any advantages of YAML over TOML YAML is older and more well supported. I'll explain to you why I ended up choosing YAML for the config files for a CLI utility written in Python that I maintain. I initially chose TOML for many of the reasons mentioned here but before my first release I ended up switching to YAML. Python added support for reading TOML to the standard library in version 3.11, however it still requires you use an external library for writing. Do I use the built in library for reading and an external library for writing? A chunk of my users are on versions of Python older than 3.11 (generally Windows users who installed Python manually at some point), do I import a separate library for THEM to read the files but use the standard library if ver >= 3.11? Now that I look at the state of things today I probably would add the tomlkit library to my setup file, but that wasn't very mature at the time, so I just used pyyaml. Changing it now would break compatibility with my older versions that use yaml config files, unless I maintained both paths... which I could do but it's just another source of complexity to worry about. These are relatively simple config files the user has to interact with manually so yaml works fine and I don't see any reason to change at this point.
amelius 3y ago
Does anyone know which format Git uses? Is it YAML? Or TOML? Or something in between?
- Gormo 3y ago
  Git uses its own ini-style conf format which diverges from TOML.
  - arp242 3y ago
    TOML wasn't even invented/specified when git came in to being.
    - amelius 3y ago
      But it looks like YAML was.
azangru 3y ago
> unlike CoffeeScript I don’t understand why people are still using it Gasp! Does this mean you know why people are still using CoffeeScript?
CuriouslyC 3y ago
YAML is an amazing config language for simple to mildly complex configs. It's easier to read and write than JSON, and it only really breaks apart when you're heavily deviating from nested lists/dictionaries with string values. People use it everywhere because by the time it becomes painful you're already so invested it's not really worth the hassle of switching.
- herpdyderp 3y ago
  I, on the other hand, find it much harder to read and write even in very simple configs. I never know what the indent is supposed to be, I just press my spacebar until my editor stops complaining. I find it really hard to tell if a line is a new entry or a subset of the parent entry. I'm sure if I used it more it'd become easier, but my whole team doesn't understand it either. Luckily we only need it for GitHub configurations.
  - basil-rash 3y ago
    YAML is (vaguely) a superset of JSON, so you can just use JSON (without tabs) and get your life back. I don’t need a config language with no fewer that 6 subtly different ways of decoding a string to remember, and certainly not one with a spec longer than C’s. Compare to JSON’s, which (famously) fits on a postcard. https://yaml.org/spec/1.2.2/ https://yaml.org/spec/1.2.2/ https://yaml-multiline.info/ https://yaml-multiline.info/ https://www.json.org/json-en.html https://www.json.org/json-en.html
- coffeebeqn 3y ago
  It’s aesthetically pleasing for simple configs. I’m so used to writing JSON by hand by now I don’t find it much easier. At least I never have to think about how a value is going to be interpreted from a JSON since it has a decent subset of types and I can visually tell what it is
- nobleach 3y ago
  Until you find a snippet of config you want to copy into your `application.yml` in Spring or Quarkus (Java frameworks). If it doesn't paste in cleanly (and it rarely ever does) you'll need to go research the schema and find out where to put things. Meanwhile, if you're using a normal `application.properties` file, after you've finished pasting, you can go on with your life.
jampekka 3y ago
I'm still using CoffeeScript whenever I can. It has one of the nicest syntaxes out there, a lot of code fits to one screenful, the logic of the code is easier to see without the clutter of unnecessary syntax and it's a joy to write too. YAML is probably used for similar reasons. I don't understand why people want redundant verbose syntax that makes reading and writing code harder. And sadly don't anymore expect anyone to really explain it based on anything tangible.
- dewbrite 3y ago
  I'm glad I'm not the only one. I prototyped an SPA recently with mithril.js and CoffeeScript and I think there's really something magical about that combo. Oddly enough I can't stand writing python or js. I do almost all of my actual programming in Rust, because I adore the type system.
dorfsmay 3y ago
I wish jdon5.org were adopted more widely, it's JSON,safe because it cannot be executed, but with comments and trailing comma! Note: YAML is a superset of JSON, which means that any YAML reader can read JSON.
jgalt212 3y ago
> why people are still using it. If support for JSON with comments was more widely available / in use, we'd use that. But it's not, so we don't.
foofie 3y ago
> I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, (...) YAML is a far better format in terms of being human readable and editable, and supports features such as node labels and repeated nodes that turn into killer features when onboarding YAML parsers into applications.
jongjong 3y ago
CoffeeScript is the worst thing that ever happened to the software industry. CoffeeScript fooled developers into thinking that transpilation was free and had absolutely no downsides whatsoever. The advantages of CoffeeScript over JavaScript were so incredibly marginal. I've never heard a single good argument about why it was worth adding a transpilation step and all the complexity that came with it. I think even TypeScript isn't worth transpilation step and bundling complexity these days, especially not when modern browsers allow you to efficiently preload scripts as modules and bypass bundling entirely. About YAML. It's also not worth it though it's not quite as infuriating as CoffeeScript. The advantage of JSON is that it's equally as human-friendly as it is software-friendly. YAML leans more towards human-friendliness and sacrifices software friendliness. For instance, you can't cleanly express YAML on a single line to pass to a bash command as you can with JSON. It's just one additional format to learn and think about which doesn't add much value. Its utility does not justify its existence.
jalapenos 3y ago
I guess the real mystery is why so many tech types speak like a infant having a tantrum, about some esoteric trivia, and then have hordes of their kind come and vigorously head-knod it, and all involved think virtue is being done. People started using things like YAML, obviously, because it reads closer to natural language. It's like a nested bullet list, which everyone can easily read. Readability is important to people. It's why we don't all still write C and Perl. So it's one thing to say "I think people should be careful about prioritizing readability over precision especially for production systems". It's another to do this narcissistic dramatic faux-incomprehension implying the markup language gained the popularity it did because everyone's stupider than you.
- runlaszlorun 3y ago
  > I guess the real mystery is why so many tech types speak like a infant having a tantrum, about some esoteric trivia, and then have hordes of their kind come and vigorously head-knod it, and all involved think virtue is being done. Ha, great line. And you caught me mid-tantrum and mid-head nod. :)
Helmut10001 3y ago
I think YAML is for code what Markdown is for Text: It is easy to read and _can_ produce the same or equal output that more strict and extensive languages. Easy readability makes this tradeoff acceptable for most.
wirrbel 3y ago
HJson https://hjson.github.io https://hjson.github.io seems a nice 'in-between' between YAML and JSON without the indentation-based syntax, so closer to the JSON side but with comments and less quotes. What I don't really get is why the cloud providers / tooling implementors have never drafted up a "YAML-light" that just throws out the rarely-used headache-inducing syntax elements.
- AndyKluger 3y ago
  Hjson is pretty nice. Two YAML-light style projects are StrictYAML (a Python library), and NestedText (an alternative spec with only string, list, and dict).
loloquwowndueo 3y ago
Oh toml is atrocious and it’s a nightmare trying to understand nesting with all those repeated keys and double brackets.
Cacti 3y ago
For everyone who hates YAML, we extend YAML to another use. It’s like without rules none of you show any common sense. Who cares what the spec says? Obviously you shouldn’t use “oN” as boolean true.
eviks 3y ago
> But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel This is optional. Besides using a better parser that uses the spec that's long fixed a lot of these listed in the article, another way to avoid the issue is adding more verbosity (that would still not match XML nor JSON). You don't have this option in XML/JSON, you can't remove all that useless markup (and leave it only when it's useful) > Why is “on” a boolean literal Because that's what humans use to denote booleans
dragonwriter 3y ago
> Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants)? ”on”, ”off”, ”yes”, ”no”, “y”, and ”n”, and case variants thereof, are not boolean literals in YAML since YAML 1.2 (2009).
- tristan957 3y ago
  As far as I know, not even libyaml supports 1.2. What YAML parsing libraries support 1.2?
  - dragonwriter 3y ago
    https://www.yaml.info/libraries/index.html https://www.yaml.info/libraries/index.html
maximilianburke 3y ago
I wonder if we would even be using YAML or TOML to the degree we are now if JSON had support for trailing commas and comments.
- Rumudiez 3y ago
  JSON5 has both of these
  - tristan957 3y ago
    I can't find any JSON5 parser that isn't for JavaScript. I've started writing one in C that can then bind to other language, but it takes time to write!
    - Dylan16807 3y ago
      Is the list on their website not good? https://github.com/json5/json5/wiki/In-the-Wild https://github.com/json5/json5/wiki/In-the-Wild And it shouldn't take much to modify an existing JSON parser.
slowmovintarget 3y ago
Obligatory: https://github.com/edn-format/edn https://github.com/edn-format/edn
wim 3y ago
Right, I also don't understand why it's considered a feature of many of these languages to introduce so many ways of doing the same thing. Like the boolean example, but also having three different ways to express a list or dictionary? It's the classic Robustness principle which makes it less robust, making reading and parsing more complicated. How about just allowing one syntax and error if it's not according to spec.
orangepurple 3y ago
[dead]
dathinab 3y ago
XML also has some other issues (no typing, to many ways to have maps but non seems to be the correct way etc.) JSON just isn't mean to be written by humans (no comments). But YAML is just horrible, like the whole accidental mistyping issues (NO => false) are just horrible and not acceptable IMHO. That it's a pretty complex thing doesn't help either. I honestly don't understand why we (e.g. github actions) still use YAML for new thinks even knowing all the issues especially if we, there are many other well suited decent but less wide spread alternatives.
ravenstine 3y ago
I've had few to no issues when using YAML for docker-compose.yml files. This isn't to say that use of YAML can't be problematic, but I don't believe it's necessarily bad at all for configuration. > So, why? In JSON, you can add templating super easily by turning it into regular JavaScript: use global variables, functions and the like. I don’t understand how anyone could prefer YAML with an ugly templating DSL over that. That's a valid use case when the target user is the software developer themself, but access to the language runtime is not something that should be accessible to a technical but non-maintainer user. Granted, it's plausible that a "template" JSON can be defined, which would be spread over a JSON-formatted configuration, but what YAML allows the user to do is define "templates" within the configuration itself and control over where those template structures are extended. When the user is a developer maintaining a software project, they should probably just use JavaScript for configuration, and not JSON files, except when there's a possibility that the configuration can be intercepted.
zamalek 3y ago
The problem goes deeper. I can't remember who coined the term, but all "implerative" (imperative declarative) languages share the same issue. I don't care if it's JSON, XML, TOML, or YAML, we shouldn't be interpreting markup/data languages. GitHub actions are a good example of everything wrong with implerative languages. Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Google zx is a good example of this done right, as is Pulumi. Kris Nóva said it best: "All config drifts towards Turing completion."
- hosh 3y ago
  I agree with all of this. If we take it one step further though and think about portability of configuration, I think that is one of the reasons we end up with operators.
- Osiris 3y ago
  For tools that allow configuration in either JSON or Javascript (like eslint), I prefer the JS version. The syntax is similar but has much more flexibility, like being able to use environment variables or add comments. Pulumi was also a good tool when I was doing kubernetes deployments.
- sixdimensional 3y ago
  "Implerative" - thank you for this, this is the term I've been searching for to describe the weird blending of the two things.. I immediately Googled it and saw that it has previous uses as well, I would love to know who originated the concept. I see so many times, confusion and arguing about what is imperative and declarative, to the point where I question the value of the terms any longer. FWIW, I have flirted with my own DSL implementations in a few cases. Certainly, language design is much more complex, but I also felt that once you understand enough of EBNF/parser generators (and some of the simpler alternatives), this is a very powerful option as well.
  - sixdimensional 3y ago
    For the curious, this might be it: "I've cracked our marketing code, y'all! Pulumi: Implerative Appfrastructure" [1] @funcOfJoe, Joe Duffy: CEO of Pulumi [1] https://twitter.com/funcOfJoe/status/1319667607214067712 https://twitter.com/funcOfJoe/status/1319667607214067712
hosh 3y ago
YAML, or TOML or Json, I think the more problematic issue is using templating at all instead of generating them.
PH95VuimJjqBqy 3y ago
stronly agree, I came to that conclusion before k8's even existed because I myself thought to use it as a configuration file format and the second I started realizing some of the ambiguity in it's syntax I walked away from it. The only thing I disagree with is that Coffeescript is still useful. I had the same reaction to Coffeescript that I had with yaml, Coffeescript _never_ had any real point outside of a segment of people preferring to write javascript in Ruby syntax. The biggest issue Coffeescript had is that debugging meant reading through the javascript anyway so you never really got away from javascript. I'm a fan of either using a full-blown programming language or ini files, and yes I realize that seems insane to many people but at the end of the day ini files are stupidly easy to edit and if you can get away with not needing a full-blown turing complete language then convention based ini files are vastly easier on the human than yaml or json. I'm either a greybeard that never got with the times or I'm a rebel, probably depends on who you talk to.
- smaudet 3y ago
  > I'm a fan of either using a full-blown programming language or ini files How do you persist complex multi-object state? Think nested lists of objects with references to one another. If your answer is still "ini files", I'm sure it can be done, but only with a lot of custom-rolled code...xml/json(even yaml) for all their issues provided a code-free way of persisting this all - either through use of marshalling (xml) or json/yaml.load().
  - PH95VuimJjqBqy 3y ago
    you cut off the part of my statement that answers your question > if you can get away with not needing a full-blown turing complete language then convention based ini files are vastly easier on the human than yaml or json. My claim isn't that ini files solve for every use case, it's that if your needs are simple enough ini files are superior to json/yaml, but that full-blown turing complete languages are superior to everything else. Also, if you're saving complex object state you don't have a configuration format but a serialization format and definitely ini isn't good for that.
xena 3y ago
We're still using the CoffeeScript of JSON because YAML's UX improvments haven't been brought into the upstream JSON spec like CoffeeScript's UX improvements were brought into JavaScript.
quotemstr 3y ago
This is all because people refuse to use JSON parsers that allow comments
khimaros 3y ago
StrictYAML solves most if not all of these problems https://hitchdev.com/strictyaml/features-removed/ https://hitchdev.com/strictyaml/features-removed/
- AndyKluger 3y ago
  StrictYAML is great (and the author is in these comments!), but ultimately it's one specific library, not a format spec, so to depend on it for a project you need every person/tool doing the writing/parsing to commit to use that library (and the programming language it was written for). Again, it's a great project, but I wanted something similar that is a language-agnostic format specification, so moved on to using NestedText wherever I can.
  - hitchstory 3y ago
    It is on my to do list to make a spec and a language independent test suite but both of these things take time.
    - AndyKluger 3y ago
      I've asked you similar in the past in comments on this site, but: what do you find lacking in the NestedText spec that a new YAML-like format might do better? Why not just embrace NestedText for the task?
      - hitchstory 3y ago
        I dont know much about nested text im afraid.
throwawaymaths 3y ago
YAML is fine if you don't do weird stuff with it. (And some stupidity like the Norway problem) A good example is OpenAPI schemas, which are quite legible in the YAML. TOML has some nasty edge cases like top level arrays, arrays of objects under a key, etc.
deleted 3y ago
[deleted]
mplewis 3y ago
The answer is simple: JSON doesn’t have comments, XML isn’t human writable, and TOML isn’t well-supported by common tooling.
ForHackernews 3y ago
YAML has comments and is easier to read and write for humans than JSON.

chx 3y ago

> Are there any serious advantages of YAML over TOML? Probably not but you forget YAML came out in 2001 where TOML came out in 2013. Neither are spring chickens but inertia is a hell of a thing. For example, Symfony supports YAML, XML and PHP definitions -- but not TOML. Symfony v2 simply predates TOML and they never got around to ditch YAML for TOML because it's not worth the bothering.

bayindirh 3y ago
TOML is just an .ini file plus some syntactic and computing sugar. I can argue that TOML is actually way older than it is.
- chx 3y ago
  1. I am unaware of a standardized .ini format 2. The native types in TOML are useful.
  - bayindirh 3y ago
    This is an .ini: [section] option=value it the way you want it. ; And these are comments. That's all. I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things. I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them. It's same for INI. You can have "native types" in .ini as well. The difference is you'll be handling them explicitly yourself, and you should do that in defensive programming anway. A config file is a stream of input to your code, and if you don't guard it yourself, you agree what that entails.
    - lpointal 3y ago
      > I don't think even though TOML has some official spec Read it on https://toml.io/ https://toml.io/ (Full spec on upper-right… with its evolutions up to final 1.00 version).
      - bayindirh 3y ago
        Oh sorry, I missed a comma. It should read: "I don't think, even though TOML has some official spec, ..." Fixed the comment too. I know TOML has an official spec.
    - Brian_K_White 3y ago
      Zomg how did you magically read my brain to produce a perfect example of what I was thinking even though there is no IEEE spec? It's unpossible!
      - bayindirh 3y ago
        I used Windows 3.1 and 3.11. That's all what I'll say.
    - arp242 3y ago
      > I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them. Overall it's not that bad, see e.g. https://arp242.github.io/toml-test-matrix/ https://arp242.github.io/toml-test-matrix/ If you look at the failure details then most of them are either minor issues about where things like escape characters are/aren't allowed, or about overriding existing tables (previously the spec was ambiguous on that, and I expect that will clear up over time). Note that overview is not entirely fair because it uses the latest (unreleased) version of toml-test where I added quite a few tests. These kind of imperfections in implementations are of course true for any language, see e.g. YAML: https://matrix.yaml.info https://matrix.yaml.info – I have no reason to believe it's worse in TOML vs. YAML, XML, JSON, or anywhere else. If anything, it's probably a bit better because it's fairly simple and has a pretty decent test suite.

lucideer 3y ago

> I don’t understand why people are still using it It's a good comaparator, there are indeed a lot of similarities, but I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. It's more like Python than Coffeescript really: it's not just about simplicity & brevity, it's about terminators. Whitespace-dependent languages are often a pain to format / parse / read in many ways - Python has survived this by the skin of its teeth by being extremely strict about indentation, both in terms of the parser & also community convention. YAML hasn't had this - it remains a mess. However, both have that very attractive property of not requiring terminators, which can't really be understated. > if you really care about conciseness, there’s TOML. Are there any serious advantages of YAML over TOML? TOML's got some good properties but its handling of structures with a depth > 1 is far from concise, and pretty terrible if I'm honest.

mjevans 3y ago
TOML's sections remind me of the directory part of a filename and keys files. For the content that belongs in a typical configuration file this or the INI style roots are probably the most human approachable formats. For anything more complex maybe a database (such as SQLite?) is preferable past application bootstrap?
fsniper 3y ago
Reading yaml has the enjoyment of reading a love letter where else json has the deterimental feeling of a solicitor email. For writing, yaml is like putting out the draft, you only focus on the meaning not care for else or the form, but for json it is like finishing up your thesis with hard defined structure.
anoopelias 3y ago
> why anyone ever used Coffeescript CoffeeScript was the front runner for 'Compile to JavaScript' technology. It was the first time we could write some sane frontend code. Of course things like TypeScript came along and now we cannot unsee what we have already seen.
jeroenhd 3y ago
> I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. When Coffeescript was invented, it was an advancement on top of the awful Javascript standards at the time. It never went anywhere because Javascript caught up, but Coffeescript had a good reason for existing. Today, Coffeescript is a remnant of old frontends that nobody has bothered transpiling into Javascript yet, but back in the day it was a promising new development.

bencelaszlo 3y ago

> Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants)? Norway is also "False".

foldr 3y ago
Or more precisely, its country code 'NO' is false. I don't think there are any YAML parsers that parse the literal string 'Norway' as false.
- julian_t 3y ago
  Maybe one written by a Geordie?
- Exuma 3y ago
  It’s very obvious that’s what he means.
  - gremlinunderway 3y ago
    shrug it wasnt obvious to me. I'm glad someone explained.
  - afavour 3y ago
    It wasn’t obvious to me. I read it as the literal string “Norway” being parsed as false, which didn’t sound believable but I didn’t make the connection to NO at all.
- sgarland 3y ago
  Be the change you wish to see in the world.
  - andybak 3y ago
    I would support a move for YAML to standardize on both "NO" and "Norway" evaluating to false. It seems an obvious win for consistency.

bayindirh 3y ago

People balk at XML, but its verbosity plus DTD allows it to pull tricks which you can't do on other things. Well everything has its place, but XML is I think very well suited where you need to serialize complex things to a readable file, and verify it while being it's written and read back.

mcculley 3y ago
Indeed. I get a lot of value out of my strongly typed XML documents. I generally have code that validates them during writing and after reading. Those who don’t understand XML end up learning why it is verbose when they eventually add all of the features they need to whatever half-baked format they are using.
- robertlagrant 3y ago
  Agreed. XML is clunky, no doubt, but it's partly that the tools were just clunky. Having said that, I do like that you can flip between YAML and JSON. If we could do that with XML (attributes vs sub-elements a problem here) it would be much more useful I think.
- delta_p_delta_x 3y ago
  The 'XML is verbose' argument is exactly analogous to the 'static typing is verbose' argument. JSON is decent, but it quickly breaks down if you want to have any sort of static sanitisation on input data, and the weird `"$schema"` attribute is quite strange. YAML makes no sense whatsoever to me. XML is by far the most bulletproof human-readable serialisation-deserialisation language there is.
  - acdha 3y ago
    > The 'XML is verbose' argument is exactly analogous to the 'static typing is verbose' argument. It’s two things: the static typing analog is definitely there but I’d extend the comparison to something like the J2EE framework fetish & user-hostile tools, too. There were so many cases where understanding an XML document required understanding a dozen semi-documented “standards” and since few of the tools actually had competent implementations you were often forced to write long-form namespace references in things like selectors or repeat the same code. I worked with multiple people who were pretty gung ho about static typing everything but the constant friction of that self-inflicted toil wore over time. I sometimes wonder whether something more in the Rust spirit where the tools are smart enough not to waste your time might be more successful.

account-5 3y ago

Personally I prefer INI over nearly all configuration formats. https://github.com/madmurphy/libconfini/wiki/An-INI-critique-of-TOML https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

youerbt 3y ago
I have seen this post on HN before and I wasn't received very well AFAIR. But I can't help agreeing with its main point: so much complexity to support a few basic data types that are not sufficient for anything complex anyway.
- AndyKluger 3y ago
  If you haven't checked it out, NestedText is a great format that offers no handling of types beyond string/list/dict, leaving all that to the application reading in the values. No character needs escaping.
  - youerbt 3y ago
    Thanks, that might be just what I'm looking for!

LudwigNagasena 3y ago

Well, you can replace YAML with JSON and JS templating without changing the parser. So I guess that’s an advantage over TOML?

__jonas 3y ago

In general I am always confused that it lets you use strings unquoted, which is what allows for all these issues with ambiguity of the interpreted data type, Norway problem and all that. It also just looks odd to me, I don't see why it's necessary to allow this.

hombre_fatal 3y ago
It’s great for end users who don’t understand what a string is or don’t have to play the game of finding the hanging single quote when they write the file by hand in a textarea. On the opposite end of UX, there’s hand written JSON which is just too meticulous in some scenarios when people are writing config without editor support.
- coffeebeqn 3y ago
  That’s probably a good thing for end users but if it’s running on something that affects the live service I’d rather not have people edit the config who don’t know what a string is
- Dylan16807 3y ago
  Dealing with inline quotes is annoying, but if you care about users writing things by hand, and especially in a textarea, you should not be using a format that depends on indentation.
afavour 3y ago
It’s because YAML is designed first for readability.

torginus 3y ago

Dunno, to me YAML is the python of markup languages. YAML is decent at handling things like nesting and arrays, while TOML sucks at it. I don't dislike YAML that much. That being said, we knew since the dawn of C macros that templating languages which are not aware of syntax, are AWFUL. Likewise, writing Helm charts (the place I encountered YAML templating) is just horrible, but would be so much nicer is templates respected the YAML syntax tree and expanded at the right subnode, instead of being a text replace botch-jobs.

wkat4242 3y ago
The biggest issue I have with Yaml is that they forbid tabs. Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels. And forbidding it makes a one-keystroke action a two or four one. I really don't understand the python/Yaml hate for tabs, and as a result I don't really use either.
- torginus 3y ago
  Like with Python, any competent text editor will take care of this for you, I've never encountered this issue before.
- tvink 3y ago
  https://lists.gnu.org/archive/html/emacs-devel/2016-12/msg01000.html https://lists.gnu.org/archive/html/emacs-devel/2016-12/msg01...
  - bayindirh 3y ago
    This e-mail enters to my "favorite quotes from internet" list directly from the top.
    - bqmjjx0kac 3y ago
      It is a funny quip, but I wish they'd consider the reformatting. I find using an autoformatter reduces cognitive load while reading and writing.

brobdingnagians 3y ago

Having on and no both be Boolean literals, but of opposite values sounds like a horrible decision, a typo doesn't result in a syntax error, but instead in a completely wrong semantic misconfiguration.

BenjiWiebe 3y ago
1 vs 0 is another typo of Boolean values with opposite meanings, in quite a few languages.
- naniwaduni 3y ago
  Worse, the ability to typo 9 in some languages for 0 and flip your boolean when it should be a type error just seems like a misdesign.
  - smaudet 3y ago
    Lets hear it for true/false, and triply enforced booleans (variables represented by three or more memory locations https://en.wikipedia.org/wiki/Triple_modular_redundancy https://en.wikipedia.org/wiki/Triple_modular_redundancy) !

cmiller1 3y ago

> Are there any advantages of YAML over TOML YAML is older and more well supported. I'll explain to you why I ended up choosing YAML for the config files for a CLI utility written in Python that I maintain. I initially chose TOML for many of the reasons mentioned here but before my first release I ended up switching to YAML. Python added support for reading TOML to the standard library in version 3.11, however it still requires you use an external library for writing. Do I use the built in library for reading and an external library for writing? A chunk of my users are on versions of Python older than 3.11 (generally Windows users who installed Python manually at some point), do I import a separate library for THEM to read the files but use the standard library if ver >= 3.11? Now that I look at the state of things today I probably would add the tomlkit library to my setup file, but that wasn't very mature at the time, so I just used pyyaml. Changing it now would break compatibility with my older versions that use yaml config files, unless I maintained both paths... which I could do but it's just another source of complexity to worry about. These are relatively simple config files the user has to interact with manually so yaml works fine and I don't see any reason to change at this point.

amelius 3y ago

Does anyone know which format Git uses? Is it YAML? Or TOML? Or something in between?

Gormo 3y ago
Git uses its own ini-style conf format which diverges from TOML.
- arp242 3y ago
  TOML wasn't even invented/specified when git came in to being.
  - amelius 3y ago
    But it looks like YAML was.

azangru 3y ago

> unlike CoffeeScript I don’t understand why people are still using it Gasp! Does this mean you know why people are still using CoffeeScript?

CuriouslyC 3y ago

YAML is an amazing config language for simple to mildly complex configs. It's easier to read and write than JSON, and it only really breaks apart when you're heavily deviating from nested lists/dictionaries with string values. People use it everywhere because by the time it becomes painful you're already so invested it's not really worth the hassle of switching.

herpdyderp 3y ago
I, on the other hand, find it much harder to read and write even in very simple configs. I never know what the indent is supposed to be, I just press my spacebar until my editor stops complaining. I find it really hard to tell if a line is a new entry or a subset of the parent entry. I'm sure if I used it more it'd become easier, but my whole team doesn't understand it either. Luckily we only need it for GitHub configurations.
- basil-rash 3y ago
  YAML is (vaguely) a superset of JSON, so you can just use JSON (without tabs) and get your life back. I don’t need a config language with no fewer that 6 subtly different ways of decoding a string to remember, and certainly not one with a spec longer than C’s. Compare to JSON’s, which (famously) fits on a postcard. https://yaml.org/spec/1.2.2/ https://yaml.org/spec/1.2.2/ https://yaml-multiline.info/ https://yaml-multiline.info/ https://www.json.org/json-en.html https://www.json.org/json-en.html
coffeebeqn 3y ago
It’s aesthetically pleasing for simple configs. I’m so used to writing JSON by hand by now I don’t find it much easier. At least I never have to think about how a value is going to be interpreted from a JSON since it has a decent subset of types and I can visually tell what it is
nobleach 3y ago
Until you find a snippet of config you want to copy into your `application.yml` in Spring or Quarkus (Java frameworks). If it doesn't paste in cleanly (and it rarely ever does) you'll need to go research the schema and find out where to put things. Meanwhile, if you're using a normal `application.properties` file, after you've finished pasting, you can go on with your life.

jampekka 3y ago

I'm still using CoffeeScript whenever I can. It has one of the nicest syntaxes out there, a lot of code fits to one screenful, the logic of the code is easier to see without the clutter of unnecessary syntax and it's a joy to write too. YAML is probably used for similar reasons. I don't understand why people want redundant verbose syntax that makes reading and writing code harder. And sadly don't anymore expect anyone to really explain it based on anything tangible.

dewbrite 3y ago
I'm glad I'm not the only one. I prototyped an SPA recently with mithril.js and CoffeeScript and I think there's really something magical about that combo. Oddly enough I can't stand writing python or js. I do almost all of my actual programming in Rust, because I adore the type system.

dorfsmay 3y ago

I wish jdon5.org were adopted more widely, it's JSON,safe because it cannot be executed, but with comments and trailing comma! Note: YAML is a superset of JSON, which means that any YAML reader can read JSON.

jgalt212 3y ago

> why people are still using it. If support for JSON with comments was more widely available / in use, we'd use that. But it's not, so we don't.

foofie 3y ago

> I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, (...) YAML is a far better format in terms of being human readable and editable, and supports features such as node labels and repeated nodes that turn into killer features when onboarding YAML parsers into applications.

jongjong 3y ago

CoffeeScript is the worst thing that ever happened to the software industry. CoffeeScript fooled developers into thinking that transpilation was free and had absolutely no downsides whatsoever. The advantages of CoffeeScript over JavaScript were so incredibly marginal. I've never heard a single good argument about why it was worth adding a transpilation step and all the complexity that came with it. I think even TypeScript isn't worth transpilation step and bundling complexity these days, especially not when modern browsers allow you to efficiently preload scripts as modules and bypass bundling entirely. About YAML. It's also not worth it though it's not quite as infuriating as CoffeeScript. The advantage of JSON is that it's equally as human-friendly as it is software-friendly. YAML leans more towards human-friendliness and sacrifices software friendliness. For instance, you can't cleanly express YAML on a single line to pass to a bash command as you can with JSON. It's just one additional format to learn and think about which doesn't add much value. Its utility does not justify its existence.

jalapenos 3y ago

I guess the real mystery is why so many tech types speak like a infant having a tantrum, about some esoteric trivia, and then have hordes of their kind come and vigorously head-knod it, and all involved think virtue is being done. People started using things like YAML, obviously, because it reads closer to natural language. It's like a nested bullet list, which everyone can easily read. Readability is important to people. It's why we don't all still write C and Perl. So it's one thing to say "I think people should be careful about prioritizing readability over precision especially for production systems". It's another to do this narcissistic dramatic faux-incomprehension implying the markup language gained the popularity it did because everyone's stupider than you.

runlaszlorun 3y ago
> I guess the real mystery is why so many tech types speak like a infant having a tantrum, about some esoteric trivia, and then have hordes of their kind come and vigorously head-knod it, and all involved think virtue is being done. Ha, great line. And you caught me mid-tantrum and mid-head nod. :)

Helmut10001 3y ago

I think YAML is for code what Markdown is for Text: It is easy to read and _can_ produce the same or equal output that more strict and extensive languages. Easy readability makes this tradeoff acceptable for most.

wirrbel 3y ago

HJson https://hjson.github.io https://hjson.github.io seems a nice 'in-between' between YAML and JSON without the indentation-based syntax, so closer to the JSON side but with comments and less quotes. What I don't really get is why the cloud providers / tooling implementors have never drafted up a "YAML-light" that just throws out the rarely-used headache-inducing syntax elements.

AndyKluger 3y ago
Hjson is pretty nice. Two YAML-light style projects are StrictYAML (a Python library), and NestedText (an alternative spec with only string, list, and dict).

loloquwowndueo 3y ago

Oh toml is atrocious and it’s a nightmare trying to understand nesting with all those repeated keys and double brackets.

Cacti 3y ago

For everyone who hates YAML, we extend YAML to another use. It’s like without rules none of you show any common sense. Who cares what the spec says? Obviously you shouldn’t use “oN” as boolean true.

eviks 3y ago

> But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel This is optional. Besides using a better parser that uses the spec that's long fixed a lot of these listed in the article, another way to avoid the issue is adding more verbosity (that would still not match XML nor JSON). You don't have this option in XML/JSON, you can't remove all that useless markup (and leave it only when it's useful) > Why is “on” a boolean literal Because that's what humans use to denote booleans

dragonwriter 3y ago

> Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants)? ”on”, ”off”, ”yes”, ”no”, “y”, and ”n”, and case variants thereof, are not boolean literals in YAML since YAML 1.2 (2009).

tristan957 3y ago
As far as I know, not even libyaml supports 1.2. What YAML parsing libraries support 1.2?
- dragonwriter 3y ago
  https://www.yaml.info/libraries/index.html https://www.yaml.info/libraries/index.html

maximilianburke 3y ago

I wonder if we would even be using YAML or TOML to the degree we are now if JSON had support for trailing commas and comments.

Rumudiez 3y ago
JSON5 has both of these
- tristan957 3y ago
  I can't find any JSON5 parser that isn't for JavaScript. I've started writing one in C that can then bind to other language, but it takes time to write!
  - Dylan16807 3y ago
    Is the list on their website not good? https://github.com/json5/json5/wiki/In-the-Wild https://github.com/json5/json5/wiki/In-the-Wild And it shouldn't take much to modify an existing JSON parser.

slowmovintarget 3y ago

Obligatory: https://github.com/edn-format/edn https://github.com/edn-format/edn

wim 3y ago

Right, I also don't understand why it's considered a feature of many of these languages to introduce so many ways of doing the same thing. Like the boolean example, but also having three different ways to express a list or dictionary? It's the classic Robustness principle which makes it less robust, making reading and parsing more complicated. How about just allowing one syntax and error if it's not according to spec.

orangepurple 3y ago

[dead]

dathinab 3y ago

XML also has some other issues (no typing, to many ways to have maps but non seems to be the correct way etc.) JSON just isn't mean to be written by humans (no comments). But YAML is just horrible, like the whole accidental mistyping issues (NO => false) are just horrible and not acceptable IMHO. That it's a pretty complex thing doesn't help either. I honestly don't understand why we (e.g. github actions) still use YAML for new thinks even knowing all the issues especially if we, there are many other well suited decent but less wide spread alternatives.

ravenstine 3y ago

I've had few to no issues when using YAML for docker-compose.yml files. This isn't to say that use of YAML can't be problematic, but I don't believe it's necessarily bad at all for configuration. > So, why? In JSON, you can add templating super easily by turning it into regular JavaScript: use global variables, functions and the like. I don’t understand how anyone could prefer YAML with an ugly templating DSL over that. That's a valid use case when the target user is the software developer themself, but access to the language runtime is not something that should be accessible to a technical but non-maintainer user. Granted, it's plausible that a "template" JSON can be defined, which would be spread over a JSON-formatted configuration, but what YAML allows the user to do is define "templates" within the configuration itself and control over where those template structures are extended. When the user is a developer maintaining a software project, they should probably just use JavaScript for configuration, and not JSON files, except when there's a possibility that the configuration can be intercepted.

zamalek 3y ago

The problem goes deeper. I can't remember who coined the term, but all "implerative" (imperative declarative) languages share the same issue. I don't care if it's JSON, XML, TOML, or YAML, we shouldn't be interpreting markup/data languages. GitHub actions are a good example of everything wrong with implerative languages. Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Google zx is a good example of this done right, as is Pulumi. Kris Nóva said it best: "All config drifts towards Turing completion."

hosh 3y ago
I agree with all of this. If we take it one step further though and think about portability of configuration, I think that is one of the reasons we end up with operators.
Osiris 3y ago
For tools that allow configuration in either JSON or Javascript (like eslint), I prefer the JS version. The syntax is similar but has much more flexibility, like being able to use environment variables or add comments. Pulumi was also a good tool when I was doing kubernetes deployments.
sixdimensional 3y ago
"Implerative" - thank you for this, this is the term I've been searching for to describe the weird blending of the two things.. I immediately Googled it and saw that it has previous uses as well, I would love to know who originated the concept. I see so many times, confusion and arguing about what is imperative and declarative, to the point where I question the value of the terms any longer. FWIW, I have flirted with my own DSL implementations in a few cases. Certainly, language design is much more complex, but I also felt that once you understand enough of EBNF/parser generators (and some of the simpler alternatives), this is a very powerful option as well.
- sixdimensional 3y ago
  For the curious, this might be it: "I've cracked our marketing code, y'all! Pulumi: Implerative Appfrastructure" [1] @funcOfJoe, Joe Duffy: CEO of Pulumi [1] https://twitter.com/funcOfJoe/status/1319667607214067712 https://twitter.com/funcOfJoe/status/1319667607214067712

hosh 3y ago

YAML, or TOML or Json, I think the more problematic issue is using templating at all instead of generating them.

PH95VuimJjqBqy 3y ago

stronly agree, I came to that conclusion before k8's even existed because I myself thought to use it as a configuration file format and the second I started realizing some of the ambiguity in it's syntax I walked away from it. The only thing I disagree with is that Coffeescript is still useful. I had the same reaction to Coffeescript that I had with yaml, Coffeescript _never_ had any real point outside of a segment of people preferring to write javascript in Ruby syntax. The biggest issue Coffeescript had is that debugging meant reading through the javascript anyway so you never really got away from javascript. I'm a fan of either using a full-blown programming language or ini files, and yes I realize that seems insane to many people but at the end of the day ini files are stupidly easy to edit and if you can get away with not needing a full-blown turing complete language then convention based ini files are vastly easier on the human than yaml or json. I'm either a greybeard that never got with the times or I'm a rebel, probably depends on who you talk to.

smaudet 3y ago
> I'm a fan of either using a full-blown programming language or ini files How do you persist complex multi-object state? Think nested lists of objects with references to one another. If your answer is still "ini files", I'm sure it can be done, but only with a lot of custom-rolled code...xml/json(even yaml) for all their issues provided a code-free way of persisting this all - either through use of marshalling (xml) or json/yaml.load().
- PH95VuimJjqBqy 3y ago
  you cut off the part of my statement that answers your question > if you can get away with not needing a full-blown turing complete language then convention based ini files are vastly easier on the human than yaml or json. My claim isn't that ini files solve for every use case, it's that if your needs are simple enough ini files are superior to json/yaml, but that full-blown turing complete languages are superior to everything else. Also, if you're saving complex object state you don't have a configuration format but a serialization format and definitely ini isn't good for that.

xena 3y ago

We're still using the CoffeeScript of JSON because YAML's UX improvments haven't been brought into the upstream JSON spec like CoffeeScript's UX improvements were brought into JavaScript.

quotemstr 3y ago

This is all because people refuse to use JSON parsers that allow comments

khimaros 3y ago

StrictYAML solves most if not all of these problems https://hitchdev.com/strictyaml/features-removed/ https://hitchdev.com/strictyaml/features-removed/

AndyKluger 3y ago
StrictYAML is great (and the author is in these comments!), but ultimately it's one specific library, not a format spec, so to depend on it for a project you need every person/tool doing the writing/parsing to commit to use that library (and the programming language it was written for). Again, it's a great project, but I wanted something similar that is a language-agnostic format specification, so moved on to using NestedText wherever I can.
- hitchstory 3y ago
  It is on my to do list to make a spec and a language independent test suite but both of these things take time.
  - AndyKluger 3y ago
    I've asked you similar in the past in comments on this site, but: what do you find lacking in the NestedText spec that a new YAML-like format might do better? Why not just embrace NestedText for the task?
    - hitchstory 3y ago
      I dont know much about nested text im afraid.

throwawaymaths 3y ago

YAML is fine if you don't do weird stuff with it. (And some stupidity like the Norway problem) A good example is OpenAPI schemas, which are quite legible in the YAML. TOML has some nasty edge cases like top level arrays, arrays of objects under a key, etc.

deleted 3y ago

[deleted]

mplewis 3y ago

The answer is simple: JSON doesn’t have comments, XML isn’t human writable, and TOML isn’t well-supported by common tooling.

ForHackernews 3y ago

YAML has comments and is easier to read and write for humans than JSON.