Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • It’s because ppl are not using it correctly, it was designed for configs and now it’s being used as a programming language… a language without types and debugger. It’s frustrating devs because they find the issue at the deployment time, not the compile time.

    Personally I did never pick the YAML as a first format for the configs, only my ruby friends did that.

  • It's also terrible for configs, for many of the reasons specified in the article.
  • I actually like the SQL example.
  • right? Sensible nesting (that's how I'd break and indent a long query anyway), folding in proper code editors, proper hierarchy... what's not to like?
    by 9dev
  • I would wager that just in the time it takes me to write this comment, millions of yaml documents have been successfully parsed. Works for me. Until it doesn't. Just like anything else. No silver bullets.
  • I think a format that relies so heavily on invisible characters is terrible, but thats just me.
  • Every good editor can make these “invisible” characters visible.
  • I used to think the same but I've mellowed.

    Modern editors make this a non-issue. I use both Python and YAML fairly regularly, both have significant whitespace, and I don't have any issues with either.

    Also, because YAML doesn't involve things like curly braces all over the place, it's actually notably less friction to type rapidly by hand than something like JSON. I don't think YAML is amazing or anything like that but I do find myself nowadays preferring it, for config at any rate, over JSON.

    JSON definitely wins for machine readable data sent over a pipe though because the lack of significant whitespace means it'll compress better.

  • Put quotes around your strings an you'll be mostly fine.
  • > you'll be mostly fine.

    You mean other than when we won't be? :-(

  • And use Alpha-3 country codes which are superior in any possible way regardless of YAML :)
    by 9dev
  • It really is that simple.

    You really should not blame it on YAML that if you put a random hash value in a field that it may be a number. Like, duh. If you want a string, use quotes.

  • - "something broke" is way better than stack traces with line numbers

    That sums it up. Its the same since the days of XML. Someone decides to make something configurable externally and then everything gets put in there for convenience. Now we are programming in XML/YAML without even a stack trace (or a debugger, or call hierarchy, or type checking or ... )

  • Pretty sure strictyaml tells you which line was faulty.
  • Ctrl+F "KYAML", 0 results

    I think KYAML[1] is very relevant here. KYAML is a strict subset of yaml[2], supported natively by kubernetes tooling in most recent versions.

    In my opinion it's closer to JSON with comments than to YAML, but overall it looks like a pretty nice format, that solves some of pain points of both technologies. This is not the first nor the only JSON-with-comments format, so I wonder if it manages to break out of kubernetes world and become popular.

    [1] https://kubernetes.io/blog/2026/08/11/how-to-pretty-print-ku...

    [2] https://www.kubernetes.dev/resources/keps/5295/

  • My usage of YAML has been limited. For the times I have used it (kubenetes, docker compose, other things, etc) -- I don't get what it so special about it.

    It just seems reinventing the wheel again and again.

    I am not suggesting JSON is perfect, either. However I do prefer it to YAML (and XML) by a mile.

    It's a shame s-expressions never taken off.

      (select (id name)
        (:from users)
        (:where (= name "Peter")))
    
    Or

      (orders
        (order
          (id 1)
          (code "aa1")
          (qty 32)))
    
    
    I know - its a sample, but you get it. :-)
  • I'm still sad that JSON5 never became industry standard.

    Unlike hjson, toml and many others, JSON5 didn't try to reinvent the wheel and create a totally new syntax.

    Instead, they took 2 already well established standards (JSON and ECMAScript 5.1) and put them together.

    I think that it is pleasant enough to write by hand while not creating yet another new syntax that you have to get used to.

    [0] https://json5.org/

  • Surprised TOML didn't get mentioned in the alternatives section, it's probably my favourite configuration format.

    I'm working on a project now that uses YAML for configuration (it makes more sense in this context than TOML) and am parsing it using Rust's `serde` crate (via `serde_norway`). It's not so bad if you use `#[serde(deny_unknown_fields)]` everywhere.

  • chuckle

    Well most of that is due to 1.1 which has been deprecated god knows for how long.

    1.2 does not have the 'Norway' problem any more.

    Tooting my own horn, this is how a modern YAML library looks like nowadays:

    https://github.com/pantoniou/libfyaml

  • I read that as libfuckyaml
    by 7bit
  • > NI: Nicaragua

    Oh, what sad times are these when passing ruffians can say Nicaragua at will to old ladies! There is a pestilence upon this land, nothing is sacred!

  • There is no problem with YAML, just like there was no problem with XML at all. The problem is with the software devs who use it for the wrong thing. I just wonder why JSON doesn't get all the hate, while it is a terrible format also: it is not streamable (YAML is), it doesn't have comments... and non-standard workarounds are used for these features. Norway better than YAML, in my opinion.
  • > Norway better than YAML, in my opinion.

    I agree that Norway is better than YAML. Let's keep Norway and dump YAML.

    > There is no problem with YAML

    I am reminded of: "There are no American infidels in Baghdad. Never!"

  • YAML is (or at least, is declared by its maintainers to be) a superset of JSON, making any JSON document also a valid YAML document.

    So surely if YAML is streamable, JSON must be too?

    Or are the YAML maintainers incorrect?

    by dghf
  • What do you mean that JSON is not "streamable"?

    There are things like https://www.baeldung.com/jackson-streaming-api but maybe there's more in you definition of "streamable" that JSON doesn't satisfy.

  • There are plenty of problems with YAML as the article shows. The biggest problem with YAML is, that serializer and deserializer need to agree on rules outside of the spec, because otherwise they can be both compliant and still don't understand each other.
  • I find json annoying to write a lot of the time, but I do enjoy that it's a lot more difficult to get wrong than yaml. The json spec is pretty clear, and can be learned and memorized by any programmer in 5 minutes. I'd much rather write in a format that's slightly annoying than a format that's slightly ambiguous.
  • > I just wonder why JSON doesn't get all the hate, while it is a terrible format also: […] it doesn't have comments […]

    The lack of comments in JSON is not a bug; comments in JSON were an anti-feature. Douglas Crockford intentionally removed them to prevent developers from using comments to store parsing directives (which he saw people doing in earlier revisions).

    * https://web.archive.org/web/20120507093915/https://plus.goog...

    * 2012: https://news.ycombinator.com/item?id=3912149

  • There numerous problems with YAML. It is underdefined, ambiguous, fragile, and is just impossible to write a portable parser for.

    JSON is naive, lacks almost everything. But is supereasy to parse and read.

    As funny as it sounds, XML is overspecified. Parsing is possible and predictable but supporting the full standard (all of them) is so much work that nobody does it anyway.

    So, given the choice above, i'd go for naive simplicity.

  • I also wonder why it’s the 2012 version of the language which gets all the hate, instead of the hate being directed at Google, who doesn’t care about putting resources towards updating the main offender, Kubernetes’ YAML 1.1 parser. https://github.com/kubernetes/kubernetes/issues/34146#issuec...
    by Diti