13 ms·

Did something happen recently to get the YAML hate train going again? I get it. YAML is not perfect. Neither is JSON, TOML, XML or even code as configuration (

Did something happen recently to get the YAML hate train going again? I get it. YAML is not perfect. Neither is JSON, TOML, XML or even code as configuration (Xmonad anyone?). They each have pros and cons and projects/technologies take those in consideration and pick one. Not sure I see the point in hating on one specific configuration language. If it was that bad, nobody would use it. And if you still think it's bad anyways, you can always improve on it. But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat. But the fact is that most times the difference between them is not substantial, so the effort to make any kind of switch so you can shorten Norway is simply not worth it.

w0m 3y ago
> Did something happen recently to get the YAML hate train going again? I was all onboard the yaml hype train until I finally started using it more for the daily job. json > * in my stogy brain.
davexunit 3y ago
Write a JSON parser. Now try writing a YAML parser.
- xigoi 3y ago
  So JSON is better because it's easier to write a parser for it? By this logic, Brainfuck is the best programming language.
sanitycheck 3y ago
I think the reason everyone jumped ship from XML to JSON was that JSON is comparatively very dumb - and dumb is quick to grok. Then some of us realised JSON is actually too dumb for many things, and instead of going back to XML we made JSON Schema, OpenAPI, etc. Others of us thought that the main problem with JSON is that it's not human readable and writeable enough. So we came up with new formats like YAML. [EDIT: My timing is wrong here, sorry.] Unfortunately being human we could not resist making it much more complicated again, thus increasing cognitive load. There have been many times when in order to really understand a YAML file (full of anchors and aliases, etc) I've had to turn it into JSON. This is ridiculous.
- rafaelmn 3y ago
  >There have been many times when in order to really understand a YAML file (full of anchors and aliases, etc) I've had to turn it into JSON. This is ridiculous. There's no reason why editor couldn't inline those things in YAML to help see what's going on locally. I can't code without code navigation and stuff like type hints for inferred types. As YAML gets used for more complex stuff I think the tooling needs to catch up.
  - dragonwriter 3y ago
    > There's no reason why editor couldn't inline those things in YAML to help see what's going on locally. There's no reasons why an editor couldn't present either YAML style (block style or the JSON-like flow style) that the user prefers, and save in whichever one is preferred for storage.
  - waffletower 3y ago
    The multitude of IDE plugins and editor modes cannot (and my God should not) solve for the fundamental weaknesses of a data specification format.
    - rafaelmn 3y ago
      Referencing common data is not a weakness, but it does introduce tradeoffs - I'd take that over having to do a "have I updated every instance" whack a mole.
- rewmie 3y ago
  > Then some of us realised JSON is actually too dumb for many things, and instead of going back to XML we made JSON Schema, OpenAPI, etc. This take doesn't make any sense at all. JSON Schema is a validation tool for languages based on JSON. You build your subset language based on JSON, and you want to validate input data to check whether it complies with your format. Instead of writing your own parser, you specify your language with a high-level language and run the validation as a post-parsing step. Nothing in this usecase involves anything resembling "too dumb". OpenAPI is a language to specify your APIs. At most, it is orthogonal to JSON. Again, nothing in this usecase involves anything resembling "too dumb". JSON is just one of those tools that is a major success, and thus people come out of the woodwork projecting their frustrations and misconceptions on a scapegoat. "JSON is too dumb because I developed a JSON-based format that I need to validate." "JSON is too dumb because I need to document how my RESTful API actually works". What does JSON has to do with anything?
boxed 3y ago
> YAML is not perfect. Neither is JSON, TOML, XML or even code as configuration (Xmonad anyone?). Whataboutism and false dichotomy in one. My house isn't perfect, so it's no different than living in a cave. My car isn't perfect, so it's no different than riding a bike. France isn't perfect, so it's no different than North Korea. Macs aren't perfect, so it's no different than a slide ruler.
- Draiken 3y ago
  Care to elaborate? You wrote a lot of words but said nothing. My argument is that picking only on YAML is useless because we can find faults in all of them. There's no perfect choice, just trade-offs. What's your point?
  - nailer 3y ago
    Not the parent but the logic is fairly clear. Something being suboptimal (JSON not allowing comments unless it's JSONC) is very different from the trash heap of poor YAML design decisions shown in this article.
    - Draiken 3y ago
      Isn't this confirmation bias at work? These are poor decisions of different degrees, but they're still simply poor decisions. I have no horse in this race. I suffered with the shortcomings of all of these formats. So I don't see a point in saying "this one is in a different category of bad". YAML was built with different ideas in mind. If we are so adamant on hating on something, we should hate the projects that chose YAML over something else.
      - nailer 3y ago
        > These are poor decisions of different degrees We agree. > but they're still simply poor decisions I, the other poster, and the article writer feel a preponderance of poor decisions regarding YAML (mentioned in the story) make it much worse than a few poor decisions regarding JSON or similar.
cachehit 3y ago
>If it was that bad, nobody would use it Well, maybe they think that it's worth "hating" on it because people are using it, and they want to make people aware of the problems? I know I do, though "hating" sounds like I have malicious intent, which I do not. I am sure the creator(s) are very bright people with nothing but good intentions. But I agree with the article that YAML is frustrating to work with. The "it's not perfect, but neither is anything" argument is a bit of a cop-out in my opinion, as that can be applied to anything and everything. I feel (but don't know!) that YAML was inspired by markdown as an attempt to create a format that felt like the most natural and intuitive to read for humans, while still machine-consumable. A noble idea, but in my opinion, one that fails as soon as you have more than half a page of configuration. Then, it just becomes a pain to even figure out which parent a specific bullet belongs to. And that's not even getting into all the cleverness. I don't want to create a new language because [XKCD standards comic]. I'd prefer people use JSON or TOML as I consider those better even if they have plenty of issues on their own.
crabbone 3y ago
Yeah... this is like saying that murdering all people in line to buy ice-cream and waiting for your turn to buy ice-cream have pros and cons: either you get to buy ice-cream faster, but some people die, or you have to wait, but nobody dies. YAML is trash. There's no pros to using it. Not in any non-preposterous way. > If it was that bad, nobody would use it. If fossil fuels were so bad for the planet, nobody would use them. If super-processed fast food was so bad, nobody would eat it. If wars were so bad, nobody would fight in them. Do you sense where the problem with your argument is, or do I need more examples?
- tgv 3y ago
  That's an overblown reaction: comparing yaml use to murdering people? Come on. And you examples are flawed. > If fossil fuels were so bad for the planet, nobody would use them. It's not the planet that's using fossil fuels. > If super-processed fast food was so bad, nobody would eat it. It's probably not as you make it out to be, and another thing: food costs money. People choose with their wallets, whether you like it or not. Processed foods are usually cheaper. YAML, JSON, XML, they all cost the same; their indirect costs are really hard to measure.
  - pil0u 3y ago
    > It's not the planet that's using fossil fuels When people say "it's bad for the planet", we need to assume that "it's bad for the humanity". The planet does not really care about CO2 emissions, humans suffering/dying from them probably do. > If fossil fuels were so bad for the humanity, nobody would use them.
  - crabbone 3y ago
    > comparing yaml use to murdering people? Where do you see me comparing YAML to murdering people? Please read that place again. I compare murdering people to the inconvenience of having to wait in a queue.
  - crabbone 3y ago
    > People choose with their wallets You are very naive if you believe that. This can only work if people can meet the following requirements: * People are rational and will always or at least statistically enough times will make the best choice. * People are egotistic and will only do what's best for them, they don't consider the benefits of others. * People know everything there is to know about nutrition, they can deduce the short term and long term effects of consuming any quantity of any chemical in any combination with any other chemicals based on precise knowledge of their gut functionality, the bacteria that lives in it etc. * People should be able to predict the future, at least enough for them to be able to make rational choices about the effects of their current actions. In particular, they should be able to predict famines, invention or hybridization of species of various agricultural plants, developments in pharmaceutics helping them to combat various eating-related health problems. ---- People don't choose. They happen to eat super-processed foods, drive energy-inefficient cars, take out mortgages they cannot pay etc. Finally, eating from a dumpster is even cheaper than eating super-processed foods (whose price can very much depend on the scale of manufacturing rather than anything else). For some reason most people choose not to eat from a dumpster...
zelphirkalt 3y ago
> [...] If it was that bad, nobody would use it. Haha, if that logic held true ... we wouldn't be using lots of things. Usually people use things, because "that's how we have done it before" or "that's all we know". Not many people look for better tools frequently. They try to get something done and the moment it is working, they are done with it. People are frequently punished for trying to improve the current state, by management that tells them: "But it already works! No business value in changing it now."
- Frost1x 3y ago
  You forgot "that's the only viable option provided by the vendor." Some people are reliant on certain software as a requirement and forced into certain standards imposed on them. They don't exactly choose the standard, they have a functional requirement and the only way to achieve it in some budget/timeline may be with a third party solution that uses, say YAML.
  - Draiken 3y ago
    Yeah I've been there personally too. But why aren't we complaining about the vendor then? I find it weird that we love to complain about the YAML format instead of the projects that chose it. Given some of the emotions I saw in other responses in this thread, it looks more like a venting exercise. Which is fine, I guess. I was simply curious on why suddenly it got propped up again.
    - pavel_lishin 3y ago
      If ten thousand vendors use one subpar language, it makes sense to try to swing opinion away from the language, rather than play whackamole with eleven thousand vendors.
    - PH95VuimJjqBqy 3y ago
      because the complaint is with yaml.
      - 3y ago
DanielHB 3y ago
> And if you still think it's bad anyways, you can always improve on it. JSON is so popular probably because you _can't_ improve it! It is too entrenched.
lucideer 3y ago
> If it was that bad, nobody would use it. > IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat. This weird line seems to govern a very persistent & substantial minority of thinking in tech that I've never been able to grok. It's like a sort of "natural selection" of quality - not only have I never seen it apply in real life, there's a reasonable argument that the opposite applies (a topic on which there's been plenty written). I guess it's based on some imagined model of each individual being an intentional & fully informed (& objectively correct) decision-maker in their own tech usage; it's certainly not based in experience. I use YAML in work. A lot. It may be the filetype I interact with most. Does that make me an advocate? I use it because the tools I interact with default to it - I have not actively selected each of these tools; of the subset I have chosen myself, YAML was one of the cons in that selection process. JSON is imperfect. XML is imperfect. TOML is imperfect. YAML is not imperfect - that implies something approaching quality.
- Draiken 3y ago
  I don't think using it makes you an advocate. I totally understand the point that most of the time we're not choosing it. It has been chosen for us in one way or another and that sucks. My whole point is that we should focus on the projects using YAML instead of the format itself. Complaining about YAML at this point is like kicking a dead horse. We know it's not ideal, but saying it's crap is not gonna change anything.
  - lucideer 3y ago
    > saying it's crap is not gonna change anything. That's true, & at the end of the day, people use YAML for a reason - one that other alternatives fall down on: it's the same reason people use Markdown (& despite it having similar drawbacks to YAML it's become even more ubiquitous). Ultimately, YAML & Markdown are good for one common reason: human write-ability. A lot of people think it's about readability, but it isn't: readability may be a pro in terms of quality, but its write-ability that actually drives adoption. YAML has pretty bad readability in reality (people think it's good because they confuse readability with aesthetics), in no small part due to its non-standardised indentation (also in smaller part due to its ambiguous data-types). JSON is probably the most readable of all of them (readability isn't about being terse or "clean"), but the requirement for terminators makes it much less write-able. XML is worse again in this regard. TOML is a kind of middle-ground - adopting many of YAML's flaws but fixing some of it's most egregious faults. Personally though, I think it seems like an odd attempt to resurrect INI, & I'd prefer something like StrictYAML[0]. [0] https://pypi.org/project/strictyaml/ https://pypi.org/project/strictyaml/
hk__2 3y ago
> Did something happen recently to get the YAML hate train going again? Not really; this website hasn’t been updated since 2018.
enlyth 3y ago
Any configuration format that cannot be auto-formatted (i.e. has significant whitespace) goes straight in the trash. 90% of my time spent with YAML is usually trying to figure out if something is indented correctly.
- hk__2 3y ago
  > Any configuration format that cannot be auto-formatted (i.e. has significant whitespace) goes straight in the trash. 90% of my time spent with YAML is usually trying to figure out if something is indented correctly. What are you talking about, exactly? If I hit alt+L in IntelliJ, my YAML file is auto-formatted.
  - Defletter 3y ago
    Using IntelliJ to edit YAML files is a bit much
    - hk__2 3y ago
      > Using IntelliJ to edit YAML files is a bit much Not if those YAML files are part of a larger project, which they quite obviously are.
  - madeofpalk 3y ago
    Problem is that it's pretty easy to have "wrong" whitespace that'll get formatted to something different than you expected.
  - enlyth 3y ago
    Indentation changes the structure of the data. There is no deterministic way to auto format YAML, you have to make sure, as a human, that everything is at the right indentation level - something - a - b Is completely different to: - something - a - b
    - bandie91 3y ago
      what about stopping the little darf who writes into your files unauthorizedly?
Defletter 3y ago
Could just be one of those things where people have grumbled about something for a while, and when there's a sudden outcry that goes viral, brings the scale of the discontent into sharp relief.
- Draiken 3y ago
  Yeah, sure looks like it. With some of the emotions I'm seeing in this thread, it feels almost like catharsis for a lot of folks.
yard2010 3y ago
JSON is not perfect either but hey, you can write just the data no whitespace and everything is fine! In YAML you need to first write the data, then find the whitespace error. The next logical thing is to use handwriting for configuration files, no technology at all
pjmlp 3y ago
I use it, because I am forced to write in as means to configure products that don't give me any other option. If I was free to use any format, I would always go for XML instead.
- raffraffraff 3y ago
  D:
  - recursive 3y ago
    Oh, the days and hours I've longed to be able to put a comment in a json config file. I would also choose XML.
    - raffraffraff 3y ago
      You can put a comment in a yaml!
valenterry 3y ago
It's not about being perfect. It's about using the wrong tool for the problem. Ultimately, code as configuration is the solution. The code generates the actual configuration-data which can be of an arbitrary format (e.g. json) since no one is gonna see it anyways except for debugging. There are usually two arguments against that: 1.) code can be or become too complicated It's a non-argument because while code can and will be complicated, the same configuration in non-code will be even worse. In the worst case, people will build things around the configuration because the configuration isn't sufficiently flexible. What is true is that a single line of code is usually more complex than single line of yaml. The same can be said about assembly vs. any high level language. But it should be clear that what counts is the complexity of the overall solution, not a single line. 2.) code can be dangerous This is a valid point. You will have to sandbox/restrict it and you need to have a timeout since it could run forever - and that creates some additional complexity. I think this complexity is worth it in 90% of the cases. Even if you are not using code to generate the configuration, you probably still want to have a timeout, just in case of some malicious actor trying to use a config that takes forever to parse/execute etc. But if you say that this is a nogo, then at least use a proper configuration language such as Dhall instead of YAML. It already exists. You don't need to invent a new configuration language to avoid YAML.
- ufmace 3y ago
  I think it's more of a progression thing. The config file starts out pretty simple, enough where one of the text file formats is clearly the right solution and code is over-complex. But then it grows and grows, continuing to accumulate more depth and use more features of the format, and maybe some hacky extensions. At some point, it gets complex enough that, if you designed it from the start with that feature set, being code would obviously be the right solution. But now the transition over is hard to pull off, so it tends to get put off for longer than it should be.
  - valenterry 3y ago
    I would like to believe it, but I have my doubts. For instance looking at kubernetes, do you really think they didn't know in advance how complex things would get? My explanation is different: often configuration files are used for things that are close to infrastructure/operations and those are done by folks who are already used to yaml and who are not used to high level coding as much. It's probably not a concious decision by them, it's just what they believe is the best.
eviks 3y ago
Unfortunately people don't automagically switch to better things, especially when they aren't the ones suffering from the choice
eadmund 3y ago
> But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. No need to create a new language: S-expressions have existed for longer than I’ve been alive. > IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat. I disagree. Path-dependence is a real issue, as are local maxima. > the effort to make any kind of switch so you can shorten Norway It’s not so that one can shorten Norway; it’s to avoid silent errors (like the Excel-gene issue). Fortunately, this particular bug no longer exists in the current YAML spec.
- cobbal 3y ago
  You say "S-expressions" like it's a standard, but it's really hundreds of different standards. Maybe someone needs to create nice websites for SON (scheme object notation), RON (racket object notation), ION (IMAP object notation), CLON, CLJON, ELON, R7RON (large and small), and the rest.
simonsarris 3y ago
Probably because of things like Github Actions, which uses YAML. The correct thing to do is use the .yml (like 15 lines) to execute a script of some kind, that does the real work, and can more easily be tested, changed, and used on its own. But many people instead start writing more and more in the yaml files to do what they want, and they're left with a mess that cannot easily be run outside of github actions, so then they test it less, or other teams build parallel processes to do the same things but locally, etc
3cats-in-a-coat 3y ago
Everything that is intensely loved will eventually be intensely hated. My theory is that it attracts a type of people with borderline personality, who intensely love something then after a period of disenchantment in which they fight, reject and ignore evidence that their passion is not flawless, they abruptly switch to hating it. They’re also typically the loudest voices in a community as they always feel intensely about everything, whether positive or negative.
miroljub 3y ago
Yeah, true. Why not just use elisp, the one and only configuration language? It's amazing what you can do with it, given the appropriate platform. Some people even managed to implement a decent editor using elisp.
darthrupert 3y ago
It's just so baffling to see the industry replace things with worse things, over and over again. The upside is that sometimes we manage to do the opposite. Perhaps it's worth it.
Justsignedup 3y ago
I don't know if direct code would solve any problems of YAML, the problem is you're configuring a system that isn't runnable locally, and by the nature of that, it doesn't matter if that system is configured in js, ruby, python, brainfuck, html, or yaml, without a validator you're screwed, and if you have a js validator, no reason you can't have a yaml one. I personally think YAML has a lot of bad flaws, for one it doesn't have a schema definition similarly to JSON or XML, so you can't just say "write a yaml that conforms to this schema" and boom, autocomplete, self-documentation, etc. That's about where I landed. "If only we had the ability to run a miniature, totally unscalable, but testable architecture locally, it'd solve all my challenges of administering a system." This is just an indicator that what we have now isn't the best, it's just the one that functions. Kinda like humans, we're not the best biological organisms, we're just the ones that ended up winning.
- appplication 3y ago
  Validation is pretty solvable though. Validate your configuration schema once it’s in memory. This is what we do for our yaml configs, it takes maybe an hour or two to write something from scratch. Sure it’d be nice to have it as a core feature, but it’s not a difficult add on.
jimmaswell 3y ago
XML is perfect for everything in theory. Too bad the average programmer apparently has such an issue grokking a little complexity, adjusting their eyes to the sight of brackets, and configuring their parser correctly that we all had to throw our hands up and use dumbed down formats instead.
- nemo 3y ago
  One of my big drivers away from XML is that processing used to be insanely expensive. Over the years this has improved some, but XML parsing is still significantly less performant than any other option, especially compared to JSON or YML. Used to be a few orders of magnitude more expensive on compute to read, and that's why many folks in the industry were happy to move on, esp for cases like message passing. I've pulled XML out of a few apps over the years in apps with a lot of message passing and the throughput and performance improvements were measurable and significant. For that use case Protobufs are much better than XML and have a schema though it's a binary format, so not usable for conf files.
  - xyzzy_plugh 3y ago
    > For that use case Protobufs are much better than XML and have a schema though it's a binary format, so not usable for conf files. There's a canonical JSON representation that is widely supported: https://protobuf.dev/programming-guides/proto3/#json https://protobuf.dev/programming-guides/proto3/#json Since JSON is a subset of YAML, you can also make YAML work. There is also a text format which lies somewhere between YAML and JSON: https://protobuf.dev/reference/protobuf/textformat-spec/ https://protobuf.dev/reference/protobuf/textformat-spec/
    - nemo 3y ago
      Yes, that's very true. I actually have used json representation at previous gigs, I just wasn't up to adding the extra qualifiers. Whenever I've needed to use Protobufs, I've always found them very nice work, really. I certainly have a much warmer opinion of them than XML.
- 3y ago
Zambyte 3y ago
> YAML is not perfect. Neither is JSON, TOML, XML or even code as configuration S-expressions curiously omitted from the list of textual tree formats that are not perfect. Hmm... :-D
- afiori 3y ago
  I am honestly curious to see if someone will create a configuration language that is just s-expressions as nested json arrays
  - Zambyte 3y ago
    The worst part about that is not having the symbol type to use in JSON, so you must quote every symbol (or make your language incompatible with standard JSON).
- marcosdumay 3y ago
  S-expressions are actually quite hard to write and read when compared to TOML, and a bit more confusing then JSON (with comments).
baz00 3y ago
Not really. I personally have hated YAML with a passion since it arrived on my lap with Ansible.
- raffraffraff 3y ago
  I wonder if it's usage in puppet is different enough to be a factor... But the introduction of Hiera to Puppet was a godsend (to me) and since then I've liked it (or at least put up with it). As long as it's only used as a way to hold data, and not the code (like Kubernetes) then I'm ok with it. If I have to use a DSL like Puppet or Terraform, I much prefer to use Hiera to perform context-aware data lookups so I can write environment-agnostic infra code (with zero hardcoded values) that iterates over data. I'm sure Hiera could have been implemented in another markup, but I wouldn't like to force my other choice on anyone. YAML'll do.
jt2190 3y ago
There was an absolutely excellent essay by James Duncan Davidson, creator of the Apache Ant build tool for Java, about why XML was its configuration language, and why it was perfect at first but grew to be a huge problem. To summarize from memory: - Ant’s config needs were modest: configs were static strings, numbers, booleans, and lists - XML parser existed, was well tested, was supported by lots of tools, so was a quicker and easy way to parse configs - As Ant became successful, the configs grew more complex and started to need to be dynamic and have “control flow” - Once control flow was needed XML was no longer the best choice for config parsing, but it was too late. (The correct answer is that a scripting language is what you want here.) Edit: I posted this quote from his essay on HN back in 2020 [1]: > Now, I never intended for the file format to become a scripting language—after all, my original view of Ant was that there was a declaration of some properties that described the project and that the tasks written in Java performed all the logic. The current maintainers of Ant generally share the same feelings. But when I fused XML and task reflection in Ant, I put together something that is 70-80% of a scripting environment. I just didn't recognize it at the time. To deny that people will use it as a scripting language is equivalent to asking them to pretend that sugar isn't sweet. Edit 2: The reason you’re not seeing an “improved yaml” is because the improved version is just Python/Ruby/JS/PHP,… [1] https://news.ycombinator.com/item?id=25385443 https://news.ycombinator.com/item?id=25385443
- latchkey 3y ago
  I was the first person to use Ant outside of Sun. I committed it to the Apache cvs repo after James donated it. The initial use for it was to build the source code for what became Tomcat (also donated by Sun/James). At the time, Java didn't really have a build system. We were using Makefiles for Apache JServ, and it was horrid. Ant was a breath of fresh air. At the time, XML was the hot "new" thing. We were instantly in love with it and trying to get it to do more. Nobody could have predicted what Ant was going to turn into. It was effectively an experiment and just a step forward from what we had previously. Iterative software development at its finest. Similar to how Subversion was a better CVS. At the time Subversion was being developed (I was part of that as well), nobody could predict that a whole different model (git) would be so much better. We were all used to a centralized version control system. It is entertaining watching everyone bork on about this topic, 24 years later. By the way, Java still doesn't have a good build system. Maven and Gradle, lol.
rdtsc 3y ago
It got shoved down people's throats more. Probably because of kube. The same thing happened with XML. First people liked it then it became a monster. JSON and YAML came to rescue us. As YAML grew in use, its warts become more evident, so it became the new monster. Time for a new language to come to the rescue. The cycle repeats...
ok123456 3y ago
As it's used in CI/CD systems, it's almost as if people are making a adhoc, buggy, non-portable version of Make. I would actually love an Xmonad style configuration system for this use case. Use an actual programming language's much better grammar and resolve errors at compile time.
- kagakuninja 3y ago
  Ah yes, Make, the original "white space has meaning" disaster... A single tab in the wrong place and you are screwed.
  - ok123456 3y ago
    So we've replaced one whitespace sensitive language for another. My editor tells me when I'm doing something stupid with Make whitespace. It's impossible to do the same for yaml.
SideburnsOfDoom 3y ago
YAML in the very the basic usage is OK. You need to watch the indent, and that's mostly it. YAML using all the bells and whistles that you had no idea were even part of the spec (e.g. Anchors and Aliases) is terrible, hard to read and harder to edit.
mschaef 3y ago
> And if you still think it's bad anyways, you can always improve on it. But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. The issue is less about putting in the work to create a new language, it's about convincing a significant chunk of an ecosystem to use that new langauge. > IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat. Switching costs are non-zero and can block a switch. ie: Helm charts are built on YAML and gotmpl, even though JSON is also an option. I can make a fairly compelling argument that Helm would be better with JSON and JSonnet, but that ignores a huge amount of investment in existing Helm charts. Whatever benefits are there would be swamped by the cost in terms of additional complexity and potential porting costs.
- thinkmassive 3y ago
  This is spot on. My brief exposure to Jsonnet made me realize how superior it can be, especially for k8s manifests. Unfortunately the learning curve is steep, to the point that I've held off on attempting to introduce it anywhere new. Recently I discovered kpt (https://kpt.dev/ https://kpt.dev/), which attempts to improve the k8s manifest situation and seems to have a lot of good ideas. Considering how long it's been under development though, it may also never catch on among mainstream k8s users. Grafana recently switched their dashboard DSL to one based on Cue. I haven't yet dug into learning it, but it seems potentially even more powerful than Jsonnet. They also have the advantages of a much smaller audience (relative to k8s manifests) and of putting in the work up front to define the new language and a sample implementation (useful out of the box), not to mention making it a requirement going forward.
  - thinkmassive 3y ago
    I suppose where I was going with all that is: hopefully, as people are exposed to superior solutions within a smaller context, they might be open to considering similar alternatives for other purposes.
geodel 3y ago
> Not sure I see the point in hating on one specific configuration language. Point is most devs do not control what their employers mandate to use. Ranting a bit help them release some frustration. And how one can improve on it? It is not an individual app where I can change or upgrade a bit and be happy. > But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. So some did awful amount of work to come up with awful config language and everyone feel thankful about it. It doesn't seem right to me.
bastardoperator 3y ago
We most certainly have a problem with our society, the internet has turned from being a place of information and sharing, to boldly whining about things that impact nobody. This is the 6th time over the course of 5 years someone has shared this link on hackernews. We get it, tools aren't perfect. Do we have mods on HN that can get rid of these dupe posts?
- recursive 3y ago
  First time I saw it. My day is just a little better for having seen it.
js8 3y ago
> IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat What problem do you see in adopting Dhall?
lamontcg 3y ago
> But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. Actually a lot of people do work on creating new languages, but I think language nerds create languages for other language nerds, not really for the bulk of people who need something simple. They always want to make them functional and immutable or self-hosting or build high performance webservers with them. Things that nobody wants to do with YAML. What we need is a configuration language with the simplicity of Logo or the C that was in the old ANSI C Book. So YAML is the most flexible and bastardizable markup language and it gets used for configuration as well, even though it is terrible.
rockostrich 3y ago
As a dev at a company that almost exclusively uses HOCON for application configurations it's really sad that it doesn't have a bigger audience. I guess Lightbend is mostly to blame for that. We used it in our python projects as well for a little bit until we hit a bug with how pyhocon handles certain references and we just switched to using the java implementation to serialize configs for python apps into JSON...
somat 3y ago
I think it is sort of like the joke about programing languages. There are two types of programing languages, those that everybody hates, and those that nobody uses.
zarathustreal 3y ago
> If it was that bad, nobody would use it. >if there was something that was substantially better, we would see projects switching to it in a heartbeat. Both of these takes are extremely naive, a person’s choice of tools has almost nothing to do with the tools and everything to do with the person. Psychology governs human behavior, not logic
x3haloed 3y ago
YAML is bloody terrible, and I've hated it since the first time I was forced to use it. JSON or TOML are always preferrable, based on the use-case. If you want humans to be able to change the file, use TOML. If only machines and debug programmers need to see the file, use JSON. YAML is in this horrible in-between where it's extremely unintuitive at first glance and it's really easy to break. The only positive aspect to YAML is that it's legible. But legible is not the same as understandable. TOML is just as legible, but it's also easy to understand and change. JSON is hard to read and hard to understand, but the structure is very durable. I'm going to take a guess here and assume that there's a strong correlation between people who like Python and people who like YAML.
x3haloed 3y ago
> Not sure I see the point in hating on one specific configuration language. If it was that bad, nobody would use it. And if you still think it's bad anyways, you can always improve on it. But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. The point is that this format is like a virus. It doesn't need to be improved. It needs to go away. We already have a lot of great serialization formats that have all the use-cases covered. Whenever someone chooses to serialize configuration into YAML, they are unleashing hell upon all of the humans that have to use it. Let me put it this way. If I was designing some software to sell to you that requires a config file, why would I skip over TOML (INI), JSON, or XML to pick YAML -- a brand new format that has a lot of funny rules that take training to understand? I would be subjecting you to confusion for no good reason. If I'm designing the software for a developer, I'd use JSON or XML. If I'm designing for a non-dev, I'd use TOML. If I'm intentionally trying to cause suffering, I'd choose YAML. Edit: I wrote this comment in a way that makes it sound objective. Programmers like to think our arguments are all objective. Truthfully, I think the hate train is really about that fact that YAML seems to be very divisive -- some people really like it, and some people feel very frustrated with the format (like me). When those of us who don't like the format encounter some system, tool, or package that relies on YAML serialization, we lose our sh--. We feel that we're being subjected to a difficult and silly new format for reasons that seem entirely arbitrary.
- fragmede 3y ago
  YAML was first released in 2001, same year JSON was formalized, so if we're going to reject a language for being "new", we probably shouldn't use JSON either. It supports comments, and doesn't use commas for lists, so you don't have the trailing comma problem for diffs. It's far from perfect, but let's not lie and pretend it kills babies or something.
wiseowise 3y ago
> If it was that bad, nobody would use it Like I have a fu* choice with Gitlab ci enforced onto me by organization.
rebolek 3y ago
JSON and XML are not perfect but are simple formats with simple rules. YAML, on the other hand, is not simple. The specs are so baroque that JSON is part of it. That's my problem with YAML. Other people may have other problems, I understand that. It's nice that you believe that people tend to use good things and abandon bad things. I wish world would work like that. But it doesn't.
- ithkuil 3y ago
  The fact that YAML is a superset of JSON is the least of YAML's problems.
thayne 3y ago
I would prefer almost any of the alternatives you mentioned to yaml for most places it is used. Except for json, due to lack of comments. Although for things where you have ifs, loops, etc.like CI pipelines and ansible, it really should be using a fully featured language instead of definig a new mini-languagr inside of yaml. Yes, none of those are perfect, but that doesn't mean none of them would have been a better choice.
deleted 3y ago
[deleted]
dragonwriter 3y ago
> But the fact is that most times the difference between them is not substantial, so the effort to make any kind of switch so you can shorten Norway is simply not worth it. Switching from YAML 1.1 (2005) to YAML 1.2 (2009) for that reason makes perfect sense, I think.

w0m 3y ago

> Did something happen recently to get the YAML hate train going again? I was all onboard the yaml hype train until I finally started using it more for the daily job. json > * in my stogy brain.

davexunit 3y ago

Write a JSON parser. Now try writing a YAML parser.

xigoi 3y ago
So JSON is better because it's easier to write a parser for it? By this logic, Brainfuck is the best programming language.

sanitycheck 3y ago

I think the reason everyone jumped ship from XML to JSON was that JSON is comparatively very dumb - and dumb is quick to grok. Then some of us realised JSON is actually too dumb for many things, and instead of going back to XML we made JSON Schema, OpenAPI, etc. Others of us thought that the main problem with JSON is that it's not human readable and writeable enough. So we came up with new formats like YAML. [EDIT: My timing is wrong here, sorry.] Unfortunately being human we could not resist making it much more complicated again, thus increasing cognitive load. There have been many times when in order to really understand a YAML file (full of anchors and aliases, etc) I've had to turn it into JSON. This is ridiculous.

rafaelmn 3y ago
>There have been many times when in order to really understand a YAML file (full of anchors and aliases, etc) I've had to turn it into JSON. This is ridiculous. There's no reason why editor couldn't inline those things in YAML to help see what's going on locally. I can't code without code navigation and stuff like type hints for inferred types. As YAML gets used for more complex stuff I think the tooling needs to catch up.
- dragonwriter 3y ago
  > There's no reason why editor couldn't inline those things in YAML to help see what's going on locally. There's no reasons why an editor couldn't present either YAML style (block style or the JSON-like flow style) that the user prefers, and save in whichever one is preferred for storage.
- waffletower 3y ago
  The multitude of IDE plugins and editor modes cannot (and my God should not) solve for the fundamental weaknesses of a data specification format.
  - rafaelmn 3y ago
    Referencing common data is not a weakness, but it does introduce tradeoffs - I'd take that over having to do a "have I updated every instance" whack a mole.
rewmie 3y ago
> Then some of us realised JSON is actually too dumb for many things, and instead of going back to XML we made JSON Schema, OpenAPI, etc. This take doesn't make any sense at all. JSON Schema is a validation tool for languages based on JSON. You build your subset language based on JSON, and you want to validate input data to check whether it complies with your format. Instead of writing your own parser, you specify your language with a high-level language and run the validation as a post-parsing step. Nothing in this usecase involves anything resembling "too dumb". OpenAPI is a language to specify your APIs. At most, it is orthogonal to JSON. Again, nothing in this usecase involves anything resembling "too dumb". JSON is just one of those tools that is a major success, and thus people come out of the woodwork projecting their frustrations and misconceptions on a scapegoat. "JSON is too dumb because I developed a JSON-based format that I need to validate." "JSON is too dumb because I need to document how my RESTful API actually works". What does JSON has to do with anything?

boxed 3y ago

> YAML is not perfect. Neither is JSON, TOML, XML or even code as configuration (Xmonad anyone?). Whataboutism and false dichotomy in one. My house isn't perfect, so it's no different than living in a cave. My car isn't perfect, so it's no different than riding a bike. France isn't perfect, so it's no different than North Korea. Macs aren't perfect, so it's no different than a slide ruler.

Draiken 3y ago
Care to elaborate? You wrote a lot of words but said nothing. My argument is that picking only on YAML is useless because we can find faults in all of them. There's no perfect choice, just trade-offs. What's your point?
- nailer 3y ago
  Not the parent but the logic is fairly clear. Something being suboptimal (JSON not allowing comments unless it's JSONC) is very different from the trash heap of poor YAML design decisions shown in this article.
  - Draiken 3y ago
    Isn't this confirmation bias at work? These are poor decisions of different degrees, but they're still simply poor decisions. I have no horse in this race. I suffered with the shortcomings of all of these formats. So I don't see a point in saying "this one is in a different category of bad". YAML was built with different ideas in mind. If we are so adamant on hating on something, we should hate the projects that chose YAML over something else.
    - nailer 3y ago
      > These are poor decisions of different degrees We agree. > but they're still simply poor decisions I, the other poster, and the article writer feel a preponderance of poor decisions regarding YAML (mentioned in the story) make it much worse than a few poor decisions regarding JSON or similar.

cachehit 3y ago

>If it was that bad, nobody would use it Well, maybe they think that it's worth "hating" on it because people are using it, and they want to make people aware of the problems? I know I do, though "hating" sounds like I have malicious intent, which I do not. I am sure the creator(s) are very bright people with nothing but good intentions. But I agree with the article that YAML is frustrating to work with. The "it's not perfect, but neither is anything" argument is a bit of a cop-out in my opinion, as that can be applied to anything and everything. I feel (but don't know!) that YAML was inspired by markdown as an attempt to create a format that felt like the most natural and intuitive to read for humans, while still machine-consumable. A noble idea, but in my opinion, one that fails as soon as you have more than half a page of configuration. Then, it just becomes a pain to even figure out which parent a specific bullet belongs to. And that's not even getting into all the cleverness. I don't want to create a new language because [XKCD standards comic]. I'd prefer people use JSON or TOML as I consider those better even if they have plenty of issues on their own.

crabbone 3y ago

Yeah... this is like saying that murdering all people in line to buy ice-cream and waiting for your turn to buy ice-cream have pros and cons: either you get to buy ice-cream faster, but some people die, or you have to wait, but nobody dies. YAML is trash. There's no pros to using it. Not in any non-preposterous way. > If it was that bad, nobody would use it. If fossil fuels were so bad for the planet, nobody would use them. If super-processed fast food was so bad, nobody would eat it. If wars were so bad, nobody would fight in them. Do you sense where the problem with your argument is, or do I need more examples?

tgv 3y ago
That's an overblown reaction: comparing yaml use to murdering people? Come on. And you examples are flawed. > If fossil fuels were so bad for the planet, nobody would use them. It's not the planet that's using fossil fuels. > If super-processed fast food was so bad, nobody would eat it. It's probably not as you make it out to be, and another thing: food costs money. People choose with their wallets, whether you like it or not. Processed foods are usually cheaper. YAML, JSON, XML, they all cost the same; their indirect costs are really hard to measure.
- pil0u 3y ago
  > It's not the planet that's using fossil fuels When people say "it's bad for the planet", we need to assume that "it's bad for the humanity". The planet does not really care about CO2 emissions, humans suffering/dying from them probably do. > If fossil fuels were so bad for the humanity, nobody would use them.
- crabbone 3y ago
  > comparing yaml use to murdering people? Where do you see me comparing YAML to murdering people? Please read that place again. I compare murdering people to the inconvenience of having to wait in a queue.
- crabbone 3y ago
  > People choose with their wallets You are very naive if you believe that. This can only work if people can meet the following requirements: * People are rational and will always or at least statistically enough times will make the best choice. * People are egotistic and will only do what's best for them, they don't consider the benefits of others. * People know everything there is to know about nutrition, they can deduce the short term and long term effects of consuming any quantity of any chemical in any combination with any other chemicals based on precise knowledge of their gut functionality, the bacteria that lives in it etc. * People should be able to predict the future, at least enough for them to be able to make rational choices about the effects of their current actions. In particular, they should be able to predict famines, invention or hybridization of species of various agricultural plants, developments in pharmaceutics helping them to combat various eating-related health problems. ---- People don't choose. They happen to eat super-processed foods, drive energy-inefficient cars, take out mortgages they cannot pay etc. Finally, eating from a dumpster is even cheaper than eating super-processed foods (whose price can very much depend on the scale of manufacturing rather than anything else). For some reason most people choose not to eat from a dumpster...

zelphirkalt 3y ago

> [...] If it was that bad, nobody would use it. Haha, if that logic held true ... we wouldn't be using lots of things. Usually people use things, because "that's how we have done it before" or "that's all we know". Not many people look for better tools frequently. They try to get something done and the moment it is working, they are done with it. People are frequently punished for trying to improve the current state, by management that tells them: "But it already works! No business value in changing it now."

Frost1x 3y ago
You forgot "that's the only viable option provided by the vendor." Some people are reliant on certain software as a requirement and forced into certain standards imposed on them. They don't exactly choose the standard, they have a functional requirement and the only way to achieve it in some budget/timeline may be with a third party solution that uses, say YAML.
- Draiken 3y ago
  Yeah I've been there personally too. But why aren't we complaining about the vendor then? I find it weird that we love to complain about the YAML format instead of the projects that chose it. Given some of the emotions I saw in other responses in this thread, it looks more like a venting exercise. Which is fine, I guess. I was simply curious on why suddenly it got propped up again.
  - pavel_lishin 3y ago
    If ten thousand vendors use one subpar language, it makes sense to try to swing opinion away from the language, rather than play whackamole with eleven thousand vendors.
  - PH95VuimJjqBqy 3y ago
    because the complaint is with yaml.
    - 3y ago

DanielHB 3y ago

> And if you still think it's bad anyways, you can always improve on it. JSON is so popular probably because you _can't_ improve it! It is too entrenched.

lucideer 3y ago

> If it was that bad, nobody would use it. > IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat. This weird line seems to govern a very persistent & substantial minority of thinking in tech that I've never been able to grok. It's like a sort of "natural selection" of quality - not only have I never seen it apply in real life, there's a reasonable argument that the opposite applies (a topic on which there's been plenty written). I guess it's based on some imagined model of each individual being an intentional & fully informed (& objectively correct) decision-maker in their own tech usage; it's certainly not based in experience. I use YAML in work. A lot. It may be the filetype I interact with most. Does that make me an advocate? I use it because the tools I interact with default to it - I have not actively selected each of these tools; of the subset I have chosen myself, YAML was one of the cons in that selection process. JSON is imperfect. XML is imperfect. TOML is imperfect. YAML is not imperfect - that implies something approaching quality.

Draiken 3y ago
I don't think using it makes you an advocate. I totally understand the point that most of the time we're not choosing it. It has been chosen for us in one way or another and that sucks. My whole point is that we should focus on the projects using YAML instead of the format itself. Complaining about YAML at this point is like kicking a dead horse. We know it's not ideal, but saying it's crap is not gonna change anything.
- lucideer 3y ago
  > saying it's crap is not gonna change anything. That's true, & at the end of the day, people use YAML for a reason - one that other alternatives fall down on: it's the same reason people use Markdown (& despite it having similar drawbacks to YAML it's become even more ubiquitous). Ultimately, YAML & Markdown are good for one common reason: human write-ability. A lot of people think it's about readability, but it isn't: readability may be a pro in terms of quality, but its write-ability that actually drives adoption. YAML has pretty bad readability in reality (people think it's good because they confuse readability with aesthetics), in no small part due to its non-standardised indentation (also in smaller part due to its ambiguous data-types). JSON is probably the most readable of all of them (readability isn't about being terse or "clean"), but the requirement for terminators makes it much less write-able. XML is worse again in this regard. TOML is a kind of middle-ground - adopting many of YAML's flaws but fixing some of it's most egregious faults. Personally though, I think it seems like an odd attempt to resurrect INI, & I'd prefer something like StrictYAML[0]. [0] https://pypi.org/project/strictyaml/ https://pypi.org/project/strictyaml/

hk__2 3y ago

> Did something happen recently to get the YAML hate train going again? Not really; this website hasn’t been updated since 2018.

enlyth 3y ago

Any configuration format that cannot be auto-formatted (i.e. has significant whitespace) goes straight in the trash. 90% of my time spent with YAML is usually trying to figure out if something is indented correctly.

hk__2 3y ago
> Any configuration format that cannot be auto-formatted (i.e. has significant whitespace) goes straight in the trash. 90% of my time spent with YAML is usually trying to figure out if something is indented correctly. What are you talking about, exactly? If I hit alt+L in IntelliJ, my YAML file is auto-formatted.
- Defletter 3y ago
  Using IntelliJ to edit YAML files is a bit much
  - hk__2 3y ago
    > Using IntelliJ to edit YAML files is a bit much Not if those YAML files are part of a larger project, which they quite obviously are.
- madeofpalk 3y ago
  Problem is that it's pretty easy to have "wrong" whitespace that'll get formatted to something different than you expected.
- enlyth 3y ago
  Indentation changes the structure of the data. There is no deterministic way to auto format YAML, you have to make sure, as a human, that everything is at the right indentation level - something - a - b Is completely different to: - something - a - b
  - bandie91 3y ago
    what about stopping the little darf who writes into your files unauthorizedly?

Defletter 3y ago

Could just be one of those things where people have grumbled about something for a while, and when there's a sudden outcry that goes viral, brings the scale of the discontent into sharp relief.

Draiken 3y ago
Yeah, sure looks like it. With some of the emotions I'm seeing in this thread, it feels almost like catharsis for a lot of folks.

yard2010 3y ago

JSON is not perfect either but hey, you can write just the data no whitespace and everything is fine! In YAML you need to first write the data, then find the whitespace error. The next logical thing is to use handwriting for configuration files, no technology at all

pjmlp 3y ago

I use it, because I am forced to write in as means to configure products that don't give me any other option. If I was free to use any format, I would always go for XML instead.

raffraffraff 3y ago
D:
- recursive 3y ago
  Oh, the days and hours I've longed to be able to put a comment in a json config file. I would also choose XML.
  - raffraffraff 3y ago
    You can put a comment in a yaml!

valenterry 3y ago

It's not about being perfect. It's about using the wrong tool for the problem. Ultimately, code as configuration is the solution. The code generates the actual configuration-data which can be of an arbitrary format (e.g. json) since no one is gonna see it anyways except for debugging. There are usually two arguments against that: 1.) code can be or become too complicated It's a non-argument because while code can and will be complicated, the same configuration in non-code will be even worse. In the worst case, people will build things around the configuration because the configuration isn't sufficiently flexible. What is true is that a single line of code is usually more complex than single line of yaml. The same can be said about assembly vs. any high level language. But it should be clear that what counts is the complexity of the overall solution, not a single line. 2.) code can be dangerous This is a valid point. You will have to sandbox/restrict it and you need to have a timeout since it could run forever - and that creates some additional complexity. I think this complexity is worth it in 90% of the cases. Even if you are not using code to generate the configuration, you probably still want to have a timeout, just in case of some malicious actor trying to use a config that takes forever to parse/execute etc. But if you say that this is a nogo, then at least use a proper configuration language such as Dhall instead of YAML. It already exists. You don't need to invent a new configuration language to avoid YAML.

ufmace 3y ago
I think it's more of a progression thing. The config file starts out pretty simple, enough where one of the text file formats is clearly the right solution and code is over-complex. But then it grows and grows, continuing to accumulate more depth and use more features of the format, and maybe some hacky extensions. At some point, it gets complex enough that, if you designed it from the start with that feature set, being code would obviously be the right solution. But now the transition over is hard to pull off, so it tends to get put off for longer than it should be.
- valenterry 3y ago
  I would like to believe it, but I have my doubts. For instance looking at kubernetes, do you really think they didn't know in advance how complex things would get? My explanation is different: often configuration files are used for things that are close to infrastructure/operations and those are done by folks who are already used to yaml and who are not used to high level coding as much. It's probably not a concious decision by them, it's just what they believe is the best.

eviks 3y ago

Unfortunately people don't automagically switch to better things, especially when they aren't the ones suffering from the choice

eadmund 3y ago

> But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. No need to create a new language: S-expressions have existed for longer than I’ve been alive. > IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat. I disagree. Path-dependence is a real issue, as are local maxima. > the effort to make any kind of switch so you can shorten Norway It’s not so that one can shorten Norway; it’s to avoid silent errors (like the Excel-gene issue). Fortunately, this particular bug no longer exists in the current YAML spec.

cobbal 3y ago
You say "S-expressions" like it's a standard, but it's really hundreds of different standards. Maybe someone needs to create nice websites for SON (scheme object notation), RON (racket object notation), ION (IMAP object notation), CLON, CLJON, ELON, R7RON (large and small), and the rest.

simonsarris 3y ago

Probably because of things like Github Actions, which uses YAML. The correct thing to do is use the .yml (like 15 lines) to execute a script of some kind, that does the real work, and can more easily be tested, changed, and used on its own. But many people instead start writing more and more in the yaml files to do what they want, and they're left with a mess that cannot easily be run outside of github actions, so then they test it less, or other teams build parallel processes to do the same things but locally, etc

3cats-in-a-coat 3y ago

Everything that is intensely loved will eventually be intensely hated. My theory is that it attracts a type of people with borderline personality, who intensely love something then after a period of disenchantment in which they fight, reject and ignore evidence that their passion is not flawless, they abruptly switch to hating it. They’re also typically the loudest voices in a community as they always feel intensely about everything, whether positive or negative.

miroljub 3y ago

Yeah, true. Why not just use elisp, the one and only configuration language? It's amazing what you can do with it, given the appropriate platform. Some people even managed to implement a decent editor using elisp.

darthrupert 3y ago

It's just so baffling to see the industry replace things with worse things, over and over again. The upside is that sometimes we manage to do the opposite. Perhaps it's worth it.

Justsignedup 3y ago

I don't know if direct code would solve any problems of YAML, the problem is you're configuring a system that isn't runnable locally, and by the nature of that, it doesn't matter if that system is configured in js, ruby, python, brainfuck, html, or yaml, without a validator you're screwed, and if you have a js validator, no reason you can't have a yaml one. I personally think YAML has a lot of bad flaws, for one it doesn't have a schema definition similarly to JSON or XML, so you can't just say "write a yaml that conforms to this schema" and boom, autocomplete, self-documentation, etc. That's about where I landed. "If only we had the ability to run a miniature, totally unscalable, but testable architecture locally, it'd solve all my challenges of administering a system." This is just an indicator that what we have now isn't the best, it's just the one that functions. Kinda like humans, we're not the best biological organisms, we're just the ones that ended up winning.

appplication 3y ago
Validation is pretty solvable though. Validate your configuration schema once it’s in memory. This is what we do for our yaml configs, it takes maybe an hour or two to write something from scratch. Sure it’d be nice to have it as a core feature, but it’s not a difficult add on.

jimmaswell 3y ago

XML is perfect for everything in theory. Too bad the average programmer apparently has such an issue grokking a little complexity, adjusting their eyes to the sight of brackets, and configuring their parser correctly that we all had to throw our hands up and use dumbed down formats instead.

nemo 3y ago
One of my big drivers away from XML is that processing used to be insanely expensive. Over the years this has improved some, but XML parsing is still significantly less performant than any other option, especially compared to JSON or YML. Used to be a few orders of magnitude more expensive on compute to read, and that's why many folks in the industry were happy to move on, esp for cases like message passing. I've pulled XML out of a few apps over the years in apps with a lot of message passing and the throughput and performance improvements were measurable and significant. For that use case Protobufs are much better than XML and have a schema though it's a binary format, so not usable for conf files.
- xyzzy_plugh 3y ago
  > For that use case Protobufs are much better than XML and have a schema though it's a binary format, so not usable for conf files. There's a canonical JSON representation that is widely supported: https://protobuf.dev/programming-guides/proto3/#json https://protobuf.dev/programming-guides/proto3/#json Since JSON is a subset of YAML, you can also make YAML work. There is also a text format which lies somewhere between YAML and JSON: https://protobuf.dev/reference/protobuf/textformat-spec/ https://protobuf.dev/reference/protobuf/textformat-spec/
  - nemo 3y ago
    Yes, that's very true. I actually have used json representation at previous gigs, I just wasn't up to adding the extra qualifiers. Whenever I've needed to use Protobufs, I've always found them very nice work, really. I certainly have a much warmer opinion of them than XML.
3y ago

Zambyte 3y ago

> YAML is not perfect. Neither is JSON, TOML, XML or even code as configuration S-expressions curiously omitted from the list of textual tree formats that are not perfect. Hmm... :-D

afiori 3y ago
I am honestly curious to see if someone will create a configuration language that is just s-expressions as nested json arrays
- Zambyte 3y ago
  The worst part about that is not having the symbol type to use in JSON, so you must quote every symbol (or make your language incompatible with standard JSON).
marcosdumay 3y ago
S-expressions are actually quite hard to write and read when compared to TOML, and a bit more confusing then JSON (with comments).

baz00 3y ago

Not really. I personally have hated YAML with a passion since it arrived on my lap with Ansible.

raffraffraff 3y ago
I wonder if it's usage in puppet is different enough to be a factor... But the introduction of Hiera to Puppet was a godsend (to me) and since then I've liked it (or at least put up with it). As long as it's only used as a way to hold data, and not the code (like Kubernetes) then I'm ok with it. If I have to use a DSL like Puppet or Terraform, I much prefer to use Hiera to perform context-aware data lookups so I can write environment-agnostic infra code (with zero hardcoded values) that iterates over data. I'm sure Hiera could have been implemented in another markup, but I wouldn't like to force my other choice on anyone. YAML'll do.

jt2190 3y ago

There was an absolutely excellent essay by James Duncan Davidson, creator of the Apache Ant build tool for Java, about why XML was its configuration language, and why it was perfect at first but grew to be a huge problem. To summarize from memory: - Ant’s config needs were modest: configs were static strings, numbers, booleans, and lists - XML parser existed, was well tested, was supported by lots of tools, so was a quicker and easy way to parse configs - As Ant became successful, the configs grew more complex and started to need to be dynamic and have “control flow” - Once control flow was needed XML was no longer the best choice for config parsing, but it was too late. (The correct answer is that a scripting language is what you want here.) Edit: I posted this quote from his essay on HN back in 2020 [1]: > Now, I never intended for the file format to become a scripting language—after all, my original view of Ant was that there was a declaration of some properties that described the project and that the tasks written in Java performed all the logic. The current maintainers of Ant generally share the same feelings. But when I fused XML and task reflection in Ant, I put together something that is 70-80% of a scripting environment. I just didn't recognize it at the time. To deny that people will use it as a scripting language is equivalent to asking them to pretend that sugar isn't sweet. Edit 2: The reason you’re not seeing an “improved yaml” is because the improved version is just Python/Ruby/JS/PHP,… [1] https://news.ycombinator.com/item?id=25385443 https://news.ycombinator.com/item?id=25385443

latchkey 3y ago
I was the first person to use Ant outside of Sun. I committed it to the Apache cvs repo after James donated it. The initial use for it was to build the source code for what became Tomcat (also donated by Sun/James). At the time, Java didn't really have a build system. We were using Makefiles for Apache JServ, and it was horrid. Ant was a breath of fresh air. At the time, XML was the hot "new" thing. We were instantly in love with it and trying to get it to do more. Nobody could have predicted what Ant was going to turn into. It was effectively an experiment and just a step forward from what we had previously. Iterative software development at its finest. Similar to how Subversion was a better CVS. At the time Subversion was being developed (I was part of that as well), nobody could predict that a whole different model (git) would be so much better. We were all used to a centralized version control system. It is entertaining watching everyone bork on about this topic, 24 years later. By the way, Java still doesn't have a good build system. Maven and Gradle, lol.

rdtsc 3y ago

It got shoved down people's throats more. Probably because of kube. The same thing happened with XML. First people liked it then it became a monster. JSON and YAML came to rescue us. As YAML grew in use, its warts become more evident, so it became the new monster. Time for a new language to come to the rescue. The cycle repeats...

ok123456 3y ago

As it's used in CI/CD systems, it's almost as if people are making a adhoc, buggy, non-portable version of Make. I would actually love an Xmonad style configuration system for this use case. Use an actual programming language's much better grammar and resolve errors at compile time.

kagakuninja 3y ago
Ah yes, Make, the original "white space has meaning" disaster... A single tab in the wrong place and you are screwed.
- ok123456 3y ago
  So we've replaced one whitespace sensitive language for another. My editor tells me when I'm doing something stupid with Make whitespace. It's impossible to do the same for yaml.

SideburnsOfDoom 3y ago

YAML in the very the basic usage is OK. You need to watch the indent, and that's mostly it. YAML using all the bells and whistles that you had no idea were even part of the spec (e.g. Anchors and Aliases) is terrible, hard to read and harder to edit.

mschaef 3y ago

> And if you still think it's bad anyways, you can always improve on it. But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. The issue is less about putting in the work to create a new language, it's about convincing a significant chunk of an ecosystem to use that new langauge. > IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat. Switching costs are non-zero and can block a switch. ie: Helm charts are built on YAML and gotmpl, even though JSON is also an option. I can make a fairly compelling argument that Helm would be better with JSON and JSonnet, but that ignores a huge amount of investment in existing Helm charts. Whatever benefits are there would be swamped by the cost in terms of additional complexity and potential porting costs.

thinkmassive 3y ago
This is spot on. My brief exposure to Jsonnet made me realize how superior it can be, especially for k8s manifests. Unfortunately the learning curve is steep, to the point that I've held off on attempting to introduce it anywhere new. Recently I discovered kpt (https://kpt.dev/ https://kpt.dev/), which attempts to improve the k8s manifest situation and seems to have a lot of good ideas. Considering how long it's been under development though, it may also never catch on among mainstream k8s users. Grafana recently switched their dashboard DSL to one based on Cue. I haven't yet dug into learning it, but it seems potentially even more powerful than Jsonnet. They also have the advantages of a much smaller audience (relative to k8s manifests) and of putting in the work up front to define the new language and a sample implementation (useful out of the box), not to mention making it a requirement going forward.
- thinkmassive 3y ago
  I suppose where I was going with all that is: hopefully, as people are exposed to superior solutions within a smaller context, they might be open to considering similar alternatives for other purposes.

geodel 3y ago

> Not sure I see the point in hating on one specific configuration language. Point is most devs do not control what their employers mandate to use. Ranting a bit help them release some frustration. And how one can improve on it? It is not an individual app where I can change or upgrade a bit and be happy. > But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. So some did awful amount of work to come up with awful config language and everyone feel thankful about it. It doesn't seem right to me.

bastardoperator 3y ago

We most certainly have a problem with our society, the internet has turned from being a place of information and sharing, to boldly whining about things that impact nobody. This is the 6th time over the course of 5 years someone has shared this link on hackernews. We get it, tools aren't perfect. Do we have mods on HN that can get rid of these dupe posts?

recursive 3y ago
First time I saw it. My day is just a little better for having seen it.

js8 3y ago

> IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat What problem do you see in adopting Dhall?

lamontcg 3y ago

> But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. Actually a lot of people do work on creating new languages, but I think language nerds create languages for other language nerds, not really for the bulk of people who need something simple. They always want to make them functional and immutable or self-hosting or build high performance webservers with them. Things that nobody wants to do with YAML. What we need is a configuration language with the simplicity of Logo or the C that was in the old ANSI C Book. So YAML is the most flexible and bastardizable markup language and it gets used for configuration as well, even though it is terrible.

rockostrich 3y ago

As a dev at a company that almost exclusively uses HOCON for application configurations it's really sad that it doesn't have a bigger audience. I guess Lightbend is mostly to blame for that. We used it in our python projects as well for a little bit until we hit a bug with how pyhocon handles certain references and we just switched to using the java implementation to serialize configs for python apps into JSON...

somat 3y ago

I think it is sort of like the joke about programing languages. There are two types of programing languages, those that everybody hates, and those that nobody uses.

zarathustreal 3y ago

> If it was that bad, nobody would use it. >if there was something that was substantially better, we would see projects switching to it in a heartbeat. Both of these takes are extremely naive, a person’s choice of tools has almost nothing to do with the tools and everything to do with the person. Psychology governs human behavior, not logic

x3haloed 3y ago

YAML is bloody terrible, and I've hated it since the first time I was forced to use it. JSON or TOML are always preferrable, based on the use-case. If you want humans to be able to change the file, use TOML. If only machines and debug programmers need to see the file, use JSON. YAML is in this horrible in-between where it's extremely unintuitive at first glance and it's really easy to break. The only positive aspect to YAML is that it's legible. But legible is not the same as understandable. TOML is just as legible, but it's also easy to understand and change. JSON is hard to read and hard to understand, but the structure is very durable. I'm going to take a guess here and assume that there's a strong correlation between people who like Python and people who like YAML.

x3haloed 3y ago

> Not sure I see the point in hating on one specific configuration language. If it was that bad, nobody would use it. And if you still think it's bad anyways, you can always improve on it. But very few actually want to put on the enormous amount of work needed to improve YAML or create a new language. The point is that this format is like a virus. It doesn't need to be improved. It needs to go away. We already have a lot of great serialization formats that have all the use-cases covered. Whenever someone chooses to serialize configuration into YAML, they are unleashing hell upon all of the humans that have to use it. Let me put it this way. If I was designing some software to sell to you that requires a config file, why would I skip over TOML (INI), JSON, or XML to pick YAML -- a brand new format that has a lot of funny rules that take training to understand? I would be subjecting you to confusion for no good reason. If I'm designing the software for a developer, I'd use JSON or XML. If I'm designing for a non-dev, I'd use TOML. If I'm intentionally trying to cause suffering, I'd choose YAML. Edit: I wrote this comment in a way that makes it sound objective. Programmers like to think our arguments are all objective. Truthfully, I think the hate train is really about that fact that YAML seems to be very divisive -- some people really like it, and some people feel very frustrated with the format (like me). When those of us who don't like the format encounter some system, tool, or package that relies on YAML serialization, we lose our sh--. We feel that we're being subjected to a difficult and silly new format for reasons that seem entirely arbitrary.

fragmede 3y ago
YAML was first released in 2001, same year JSON was formalized, so if we're going to reject a language for being "new", we probably shouldn't use JSON either. It supports comments, and doesn't use commas for lists, so you don't have the trailing comma problem for diffs. It's far from perfect, but let's not lie and pretend it kills babies or something.

wiseowise 3y ago

> If it was that bad, nobody would use it Like I have a fu* choice with Gitlab ci enforced onto me by organization.

rebolek 3y ago

JSON and XML are not perfect but are simple formats with simple rules. YAML, on the other hand, is not simple. The specs are so baroque that JSON is part of it. That's my problem with YAML. Other people may have other problems, I understand that. It's nice that you believe that people tend to use good things and abandon bad things. I wish world would work like that. But it doesn't.

ithkuil 3y ago
The fact that YAML is a superset of JSON is the least of YAML's problems.

thayne 3y ago

I would prefer almost any of the alternatives you mentioned to yaml for most places it is used. Except for json, due to lack of comments. Although for things where you have ifs, loops, etc.like CI pipelines and ansible, it really should be using a fully featured language instead of definig a new mini-languagr inside of yaml. Yes, none of those are perfect, but that doesn't mean none of them would have been a better choice.

deleted 3y ago

[deleted]

dragonwriter 3y ago

> But the fact is that most times the difference between them is not substantial, so the effort to make any kind of switch so you can shorten Norway is simply not worth it. Switching from YAML 1.1 (2005) to YAML 1.2 (2009) for that reason makes perfect sense, I think.