That's a Lot of YAML
noyaml.com
noyaml.com
- 07
- 08
[ 7, "08" ]
This assumption was discovered deep within some templated YAML generated by templated something else three levels down and resulted in a complete k8s cluster failure for us, but only the 08 cluster! It worked in the first 7.
But fuck this particular type conversion semantic.
Here's a relevant suggestion from the Ansible docs (https://docs.ansible.com/ansible/latest/collections/ansible/...):
For those used to /usr/bin/chmod remember that modes are actually octal numbers. You must give Ansible enough information to parse them correctly. For consistent results, quote octal numbers (for example, '644' or '1777') so Ansible receives a string and can do its own conversion from string into number. Adding a leading zero (for example, 0755) works sometimes, but can fail in loops and some other circumstances.
This actually made me LOL, that's amazing
07 is the octal number 7.
08 is not a number.
Did you read the spec? Or did you just start using it assuming you knew how it worked?
Whatever generated that clearly wasn't serializing its data using a library, or it would have converted the type into the correct format.
Wow, you couldn't ask for a stronger condemnation than that for YAML as a configuration language. "You clearly weren't using a library to write your config file".
In the world I live in, config file formats exist to be written and read by humans. Serialization formats exist to be generated by libraries.
But it's not unreasonable to expect 07 and 08 to work consistently.
CI/CD always has some logic, and it's almost never in pure YAML but also has some weird templating going on. Like, please, couldn't you just have a real API for some real programming language.
I think a lack of type safety is the main problem with YAML - a wrong indentation, a typo in a key, a string that gets parsed as a boolean, etc.
Other than that I think it's a great format - terse and far less syntactic noise than other formats. This is why I wrote https://github.com/crdoconnor/strictyaml so people could write type safe yaml and get instantaneous, clear error messages on those things.
absolutely true, but the same happened to XML. XML is actually awesome with tooling that hasn't been matched to this day (XSD, XSLT, just to name a few).
But people abused it, it got a bad rap, browsers made JSON preferable, etc.
But the point is that companies are using YAML for these things and we're starting to see attitudes shift just like they did when the industry went nuts and abused XML.
People will just pull in abstractions because they think it is needed. This is why I always avoid using Turing complete programming languages as a configuration format.
I've spent hours using a JavaScript debugger to step through AWS CDK. A simple, dumb yaml/Json/whatever file wouldn't have that problem (and it was a small project, the complexity wasn't needed). Sure, there might be use-cases where you need to be able to do more. But until now, I've never seen that.
This is why I also prefer JSON over JS in JS tool configuration. This is why webpack configs get so messy. As soon as people can use a real language, their "DRY sensor" (or other bad applied paradigm sensor) triggers and they make things more complicated.
Being declarative also makes it easier to follow standard practice and supports tooling. Imagine the package.json would actually be like a build.gradle. That would make things much worse.
I've had to convert 50k class-based schemas to a declarative DSL; the requirement is to be declarative, not rely on external state. and portable as-is with as little interpretation as possible.
The flexibility of a language means some bug deep in a library will cause your infra to delete or misconfigureitself on accident.
An API requires transactions or at the very least a read-modify-write cycle. The API need to always be up so engineers can merge their modifications to infrastructure. Recovery and undo is also a problem that needs to be solved so you need a system with point in time recovery.
My Preference is to have an actual language generate what the system will do in a human-readable format, and you check that in, but Git and JSON or YAML with a Proto DSL act as the API, and then anything that can write a flat file can be used to configure your system.
As a file-format, YAML has pros and cons. But the real problem is in trying to use a JSON-equivalent file format to describe things that have conditionals, loops, functions, and classes/subclasses (by way of templates).
YAML is fine for small configurations. But it grows into a vendor-specific spaghetti mess very quickly, especially once you start to need any kind of control flow.
What are you thinking?
Like Jenkins Groovy plugin? I'd probably just hear how people hate Groovy.
Dagger and Pulumi SDKs are examples of typical languages used to replace config languages for certain tasks
If you want to do things like that, use a real language and emit a final config value
The page mentions some alternatives like Dhall and Jsonnet. Two more to consider:
1. Write a configuration library for a real programming language. Have this library generate a JSON configuration file that is treated purely as an inspectable artifact, not something to edit by hand. The user will have their configuration as tooling-enabled code checked into version control (hopefully). That it will be harder to make an emergency fix directly on the server has its downsides and upsides.
(What was the first prominent piece of software to implement this idea? I kind of got it by osmosis.)
2. Starlark. It is a non-Turing-complete language derived from Python that was originally developed for the Bazel build system. It has several implementations (I am not sure how deeply compatible they are) and now Python bindings (https://github.com/caketop/python-starlark-go for starlark-go, https://github.com/inducer/starlark-pyo3 for starlark-rust).
If you meant that having any executable inside yaml (e.g. not just picking on jinja, but "a yaml document is not code") then I fear that ship has sailed because people realized that inverting the literal parts and only sometimes having executable parts makes for a great way to ASP/JSP/PHP up some content
If I wanted start a sibling flame war within this thread, we'd talk about HCL and for_each :rolling_eyes: (but, for clarity, please don't talk about it, or at least not here, submit your own noHCL.com link)
this is the route Amazon chose with CDK. it kinda works... but it really feels like you're building a rube goldberg machine to do anything non-trivial. how much of it is the CDK and how much is cloudformation plainly sucking I don't know.
The thought of working with Ansible again is my nightmare due to this. Apparently they had an actual Python DSL you could use instead of YAML for a while, but discontinued it? So now loops and if-thens are these awful drawn-out messes of YAML that interpret jinja in completely unpredictable ways.
I would also like to avoid writing Ansible playbooks when I need to manage servers again. Something I want to try out is Pyinfra (https://pyinfra.com/). It is like Ansible in that it is agentless and works over SSH, but with configuration in Python instead of YAML and Jinja. There is also itamae (Ruby, works over SSH or on the local machine, https://github.com/itamae-kitchen/itamae) and mitamae (mruby, local-only, https://github.com/itamae-kitchen/mitamae).
It was easier for me to deploy enterprise web-applications to our on-prem IIS that had all the load balancing and networking and whatever else done by less than a quarter of a full time employee back in the early 00’s than it is for me to deploy the same damn thing into our “modern” setup. Yes, there are advantages to our modern pipeline. We’ve moved far beyond the whole “it works on my computer” thing and we’ve increased the quality control immensely by putting up much better acceptance gates, but the actual deployment? That’s a damn nightmare in 2023.
Again, this is likely not an issue for many HN programmers who work in actual tech companies, or in companies with good dedicated DevOps teams, but in the world of non-tech enterprise CI/CD has frankly never felt worse in my career. I guess you can chose to blame YAML, and the loads of it you need to do anything and how hard templating seems to be. But in my opinion it’s far more of an organisational issue than a technical one. We need CD tools that are far more automated, so that it doesn’t become the job of the developer to describe the infrastructure as code. It’s fine that you can do that, but the reality is also that we are asking millions of developers to deploy infrastructure that they might not have the slightest clue how works. I’ve never met a developer who didn’t just want to hand off their container and then have all the networking and “server stuff” just done for them. And when you don’t, you end up with a lot of VNETs and subnets that nobody really knows how works and that your organisation is losing a ton of money on because your developers didn’t know you could so /x and then start the subnet where it came to.
You work offline on a "job definition" of some sort, submit it to the proprietary shared system, wait in a queue, then you receive a log file generated by a system you don't control. You can't run the proprietary system code locally on a workstation, and hence the inner loop is often tens of minutes long at best, hours or days at worst. There's no preview, no "what if" mode or "dry run". You work directly on production even if it's called "test" because there's only one system.
The real problem isn't YAML. It wouldn't matter if the pipelines were scripted in God's own programming language.
Software development on workstations instead of central timeshare mainframes became wildly popular because it allowed a dramatically faster inner loop, it allowed isolation from production environments, and it gave control back into the hands of the developers.
Current-generation CI/CD pipelines generally undo all of that.
Single-box Kubernetes reintroduces most of what made workstation-based development good, but it is still a very new system and has many teething issues.
PS: A related issue to yours is that there are great solutions for the solo dev doing click-ops for one app, there are great solutions for megacorops doing automation at scale for thousands of devs, but in the middle where you have a couple of enterprise devs managing a few dozen apps its just madness.
More seriously, this is a very good comparison. IBM always dreamed to be something like AWS is today.
You don't even have to squint very hard for IBM's Job Control Language to start looking an awful lot like some CI/CD pipeline YAML file.
I dunno. I've had things working on my docker image quite a few times while breaking at the deployed one.
This is only passed if you have complete transparency of the entire build and deployment pipeline, total access to the images repository, actual control over the building instructions, etc. That's about as restrictive as control over a local OS, and I do expect it to fail on about as many organizations as the ones that had problems with code breaking when moved into another machine.
As far as actually running the build images, however, if they run in Docker locally then we never have issues with running them in the cloud.
The first thing you're going to have to do is the networking. You're not going to deploy things on the internet in an Enterprise Organisation, so you're going to have something that can make sure your application gets on the right VNET and the right subnet. Obtains the correct private-endpoints. Gets a DNS address so people can go to https://yourapp.yourcompany.com from the internal on-prem network that will need a DNS routing as well because it's not going to ask the internet. Once in a while, when you actually want your app to be accessed from the internet, you're going to need some sort of gateway resource that can transfer the traffic through whatever security your org has setup in such a way that it blocks, every, IP you're not intending on letting through.
The second thing you're going to want is a place to persist your data. You can have a centralized shared database, and most places use this, but the issue with that is that it'll eventually end up a mess. Not by bad intention, but because it's just very easy to build stored procedures, views and whatever else on top of the data from all those 100+ applications that are sharing the same DB server because it's a quick way to deliver business value (until it isn't). It also doesn't scale, which will eventually be an issue for you even if you aren't netflix. The flip-side is that you can't actually do a bunch of managed DBs because that is ridicilously expensive, and you likely can't use the CosmosDB (and whatever the AWS equvilient is called) because of company red-tape and also because your 3rd party DB backup vendor doesn't support it. So you either run them in containers, or share servers, or run up the bill. Two of those solutions require all the steps in the networking step, because they too need to be on the right private endpoints on the right subnets on the right VNETs, and all of them will need you to grant some sort of access rights through your IDM. Which is often as simple as giving your apps some sort of managed ID and then adding it to some AD group, but that's still something that needs to be done.
Deployment slots: now we're moving into the more ridicilous parts of it, but you're probably going to need to deploy your application at least twice. It'll probably be three or more, but it'll be at least twice. Each of these slots require that you go through the two previous steps. If you're wondering why, then it can be as silly as because some Enterprise Architect lied in a meeting and convinced everyone it was required by law, similar to how you're also forced to put 4-6 eyes on every pull request (though to be fair, this part makes sense).
And that's if you're using serverless dockerized function apps in Azure in an enterprise organisation. If you're not doing serverless it gets way worse. Sure kubernetes, travis, openshift and so on can do it much smarter, but in non-tech enterprise you don't have anyone employed to manage it.
@jiggawatts really put it well when he said this in one of the other comments:
> there are great solutions for the solo dev doing click-ops for one app, there are great solutions for megacorops doing automation at scale for thousands of devs, but in the middle where you have a couple of enterprise devs managing a few dozen apps its just madness.
In all seriousness I've written and deployed business critical serverless applications, which are less code than the bicep and yaml required to deploy them, and here is the biggest issue, I have no idea if my bicep is actually good because GPT wrote most of it.
Never use YAML outside of the Python ecosystem.
That way, people who love esoteric scripting formats that prioritize legibility over correctness, durability, and maintainability can keep all their tab characters, loose typing, and cryptic syntax. And the rest of us never have to! Those of us who prefer C-style syntax can keep our sanity.
Edit: OK, I think I've finally got my finger on the crux of the issue here. I think I can't explain this whole thing without being spicy. For C-syntax devs like myself, syntactic whitespace is pure madness. Whitespace is not information or an instruction -- it's formatting. Good formatting is helpful and useful, and good C-syntax devs care about legible formatting. In Python (and YAML), the formatting is instructional information. This has the benefit of making all functional code legible. But why the blazes does code have to be legible to be functional? Imagine working with a YAML coworker. You send them a long message. They reply with, "What? This is nonsense." You suddenly realize your mistake. Without separating your paragraphs with an empty line, you've broken the meaning of what you sent. Adding the empty lines back in and re-sending the chat message, your co-worker can now read what you wrote. Without syntactically-accurate formatting, the information you sent was meaningless.
Those languages enforce a standard syntactic structure; there are less ways to write unreadable code, which is a good thing.
However, I came to think that the difference is not philosophical. It is just that some tools (text editors, e-mail programs, etc) support significant whitespace well, while other don't.
For example, the text editors I use are all set up to display space and tab characters, and to display them differently (usually as a faint dot and a faint mdash, or something). I am used to it, and this does not distract me at all.
From my point of view, code is not some random text. We use fixed-width fonts for it that we would not use in a book, we color-code it, I don't see why not make the white space visible.
I still have a "philosophical" preference for languages without significant whitespace, but I don't hate languages with it, they are not a problem for me at all.
But if the tools you use and love don't have good support for significant whitespace, or you won't make the whitespace visible, or even, you know, use vaiable-size fonts for coding... Well, then you will hate significant whitespace with a passion and consider it pure madness!
:-)
What changed my mind, of all things, was writing Coffeescript¹. I'm not a big fan of Javascript, and writing Coffeescript felt like a distillation of Crockford's The Good Parts book. You couldn't forget and generate the bad parts.
But additionally found the indenting as code felt quite pleasant. The only hassle is not being able to press % on an opening or closing curly brace in Vi to find the other end of the block. OTOH, with the indentation, if a piece of code looked wrong, it probably was.
Mind you, I still haven't learnt much Python.
¹ These days I use Typescript, but if they ever came out with a Coffeetypescript…
If you think you need to serialize something more complex, use XML. It might look ugly, but it’s very powerful, can be verified on many levels and has a mature ecosystem.
“Cooler” doesn’t always mean better, especially for bigger data. Neither YAML, nor JSON scales to that sizes while being readable and easy to maintain.
Also, I think TOML stdlib gets to the heart of what I've been arguing. People who like syntactic whitespace like YAML. Everyone else (like C devs) don't. It makes quite a bit of sense to me that C devs don't want to touch YAML with a 10-ft pole.
Will not immediately help in all cases of YAML usages, but at least can be a cooler way of defining resources in a Terraform-like style. In fact, it's already helpful as a replacement for HCL in one internal project, that was a final motivation to hack it.
In a bigger picture, I have no idea how to help with YAML omnipresence in Kubernetes. More than a half of my problems at a $daily_job is how crude is consolidating a final Helm chart from different sources. I am not saying that Helm would be inherently a bad tool or my company has chosen pretty bad way of using it - I guess everyone is doing their best considering the ciscumstances. But manipulating textual templates with semantic whitespaces is just too error prone, and the detection of errors happens too late. I dare to say - Kubernetes would do much better with custom format based on a C-like syntax, instead if trying to prove how cool YAML is, especially when it isn't.
There are two good features in YAML: multiline strings, and YAML is a JSON superset. You can use anything that generates JSON to generate YAML.
Nickel can be evaluated to JSON: https://nickel-lang.org/
On the sense that any JSON file is a valid YAML file.
But absolutely not in the sense that you can just treat your json file as YAML and expect it to contain the correct data.
Is it that an academic property, or are people serious about throwing JSON into running software that parses YAML and expect good results? (Should I add: on production, because I want my tools to be used on production, but that's just me)
It seems very similar.
Yeah, ucl looks syntactically similar. On the other hand, I am not sure if it has expressions, and the variables usage is limited - they need to be registered in the parser, so they are existing outside of the config file; plus, they seem to represent just text.
My assumption was to use variables in the same file, to make the content more modular/DRY, and to evaluate expressions using these variables. Moreover, variables and expressions have basic types: int, float, string and bool. This is not an artificial need, I will give you concrete examples what I want to have in the config file:
- port numbers increased from a base value (int arithmetic)
- recalculated frequency/throughput values (float arithmetic)
- fields enabled if some other condition is true (comparisons, bool arithmetic)
- names concatenated from text and numbers
What else... in BCL variables are internal to the file; I want also to resolve the information existing external to the file, which would be: env varables (planned builtin function getenv) and ideally, output of executing command (like shell's $(), also planned). With this I can express easily and shortly quite complex configurations.
Actually thanks a lot for your comment, because answering this makes me realize I should put such information in the README of my project, maybe in some more structured way.
The format itself is not without blame of course: the more flexible it is, the more easily can be repurposed into a (bad) programming language.
Having committed this mistake over and over, these days, I would pick the simplest config format possible (even .ini might be too powerful) for basic configuration, and delegate more complex "configuration" to a real programming language (possibly the same language the application is written in).
But none of the examples you see do that, and your tools won't do that. The whole YAML ecosystem nudges you into writing your stuff unquoted, and it works most of the time and breaks just often enough to trip you up in production.
It's 30% of the reason people write YAML instead of JSON.
'', "", f'', f"", b'', b"", """""", "" "", '' '', r'', r""
YAMLs strings are overblown and are just the result of having a few modifiers. Of all the things to complain about having ways to make chucks of text readable is the weirdest one. Don't even dare look at how many weird strings bash has.
It is:
- Unambiguous
- Streamable
- Extensible
- Whitespace-insensitive, but there are formatting conventions for readability
We then generate reports/statistics/feedback pdfs from the yaml files via markdown+pandoc.
For us yaml works great, as it's easy to add further feedback in markdown syntax (just correctly indented "- you missed a `NOT` here"). Via the different escape methods for block text, we can print the SQL submission nicely formatted without escape characters, etc., even when the students uses all the different SQL-delimiters. It is all plaintext, so we just use a text editor and we store that all in git and have accountability over grading. We have everything archived machine readable, so that we may test new static analysis stuff on past submissions.
But also having to write CI-pipelines and home-automation configurations in yaml, I understand the struggle.
In TOML you either just forget about indenting multi-line strings (which makes them less readable) or you have to remember to putting a backslash at the end of each line. Neither option is ideal.
This makes YAML pretty nice for DSLs or configurations that need to embed markdown or other textual format and give it an edge over something like TOML.
But I won't put the entire blame for "YAML fatigue" on all the CI and DevOps tools that chose to use it as the carrier format for their DSLs. YAML has major issues which the OP site outlined very well:
- The famous "Norway issue" (solved in YAML 1.2) - Leading zero parse as octal (solved in YAML 1.2) - Overeager type-coercion for numbers, dates, times etc. can be confusing. - Different modes for processing multi-line strings can be quite confusing. - Unsafe serialization (not an issue for modern parsers, but you need to be careful when using YAML on a veteran language with dynamic features like Ruby, Python or Java).
All of these are issues with the YAML spec itself.
If you're on the dev team, you solve the problem by programming. You also leave and/or create other problems for the devops team to solve because of microservices, 3rd party integration, etc. Depending on your dev environment, this cycle can range from incredibly quick to incredibly slow.
If you're on the devops team, you're often left with solving the problem with a configuration file only. The dev cycle for that is usually horrendous both in time and feedback on each iteration. Anything that gets in your way becomes a victim of your wrath and anger.
Most of the problems with YAML are the problems that XML had in the early Spring Java days, and most of those problems stemmed from "programming" by gluing together software via configuration files. This isn't a good pattern regardless of how you format the files.
The moment you start to reach for schema definitions and validation for your configuration language, you should consider that a warning sign. We've been down this road before. It does not lead to a good place.
looks better than normal SQL to me ...
Not that joins in SQL use a particularly intuitive notation. At the very least it doesn't make it obvious you can usually swap the order of joins around without affecting the end result.
You mentioned moving JOINs around, so I'll mention that if represented as structured data, you can move any of the top level components around, so you could more closely follow the "true order of SQL" [1]. For example, I would love to be able to put FROM before SELECT in all or almost all cases. There's also being able to share and add to something like a complicated WHERE clause, where essentially all programming languages have built-in facilities for robustly manipulating ordered and associative data compared to string manipulation, which is not well-suited for the task.
Now don't get me wrong, I don't particularly care for YAML (though it doesn't bother me that much), but as someone who's done their fair share of programmatic SQL creation and manipulation in strings, not having a native way to represent SQL as data is a mistake in my opinion.
0: https://github.com/seancorfield/honeysql#big-complicated-exa... 1: https://blog.jooq.org/a-beginners-guide-to-the-true-order-of...
What I was referring to is that 'SELECT * FROM A JOIN B ON f(A) = g(B)' and 'SELECT * FROM B JOIN A ON f(A) = g(B)' mean exactly the same thing, but this is not obvious from the language. This is especially iffy when you start joining even more tables together.
The equivalence is clear when you write out the corresponding diagram and note that the join is its limit, but your examples seem to make the same mistake SQL did by lumping together the join condition with one of the two tables.
SELECT: [num, name]
FROM: [customers]
WHERE EXISTS:
SELECT: [name]
FROM: [orders]
WHERE:
AND:
- EQUALS: [customers.num, orders.customer_num]
- LT: [price, 50]
True, it's a little side hustle that's funny but doesn't necessarily make much sense.
Millennials: “That is way too much text, it’s like way longer than an SMS message. And everything’s on the internet. Here’s JSON, which is much shorter and more Web 2.0.”
GenZ: “Bra, all those squiggly lines are sus, try this YAML. It’s dank, no cap.”
As a bonus using jq code as configuration gets you templating for free.
Or if you have a choice of markup language just use XML.
You can’t have your cake and eat it too, either use XML and deal with the verbosity or use something else with less markup but more error prone.
I personally prefer XML as verbosity is the least annoying problem to deal with.
As a result, user-supplied input can't just be escaped: it may also need to be base64 encoded or otherwise transformed into a safe alphabet.
As to your frustration with logic and code being stuffed into YAML, I totally get it. Everyone coming up with their DSL, I'm guilty of it too. I think YAML unfairly takes the blame for unnecessary abstractions built on top of it. YAMLs only fault being, that you actually can write DSLs with it easier than with anything else.
I like YAML, it is super easy to read, I like it for simple configuration, it works good for Ansible, Github actions use it. I never ran into any issues, but reading about it I get why people do not like some parts of it. I think it may have to many features that nobody uses, but the features to cloning and injecting and merging content is are kind of cool, used them once for config that got a lot or repeated stuff.
I barely use it and even I can see 80% of these issues are from not putting quotes around your values.
Maybe config languages are just really easy to bike shed.
I think some of the problems come from different areas using similar languages. There are data serialization langugages, JSON is good for this. Then there are configuration languages, which need to be human editable, YAML is good for this. Then there are configuration languages that generate configurations. Shoehorning this into YAML/JSON makes a mess. Better to have dedicated language and output JSON for API.
I have a project where I'm using YAML just for that: nested tree-like (data) declarations and reasonably succinct and relaxed syntax. I have run into some of YAML's parsing weirdness occasionally, but overall it hasn't been that bad to deal with when it happens.
S-expressions. A parser for s-expressions (with no evaluation) can be as small as 300 lines of C code.
It'd take a day to write, and can express everything in a way that:
1. Current IDEs and code-editors can semantic-highlight
2. Current IDEs and code-editors can auto-format
Add in builtins for setting/getting symbols, and you can also DRY your config with variables and functions.
[EDIT: The DRY is optional - if you don't want someone messing up configs down the line, then don't implement any builtins that modify the symbol table, just examine the tree in your program after you have read in the s-expressions.]
Composite data types, nested objects, alists, lists, trees, tables...
With only a few primitive additions, you should be able to represent everything, except for bidirectional cyclic graphs.
I think, at least for me, when I'm writing JSON in a document I can just go "I need a map, type `{`" and "I need a list, type `[`" and I like that.
I think my biggest gripe with YAML, TOML, etc is that to save me a few keystrokes I often end up playing this game of "Ok now how will the library interpret this, I'm adding a line here, it's indented, let me scroll up, ok, the last logical thing that happened was X so it's going to interpret this as a list item..." and that feels so taxing to me.
Though stylistically it appears flat.
HOCON
Though if you're trying escape complexity, it doesn't count.
Jsonnet
Though this is Turing-complete.
Yeah, declarative DAGs 101 lol(?)
Does python code get generated from the Yaml, or does python code load the Yaml and do Airflow tasks?
I never thought specifying DAGs in airflow / python was that difficult. What problem is this solving?
I have a thing that does CUE + text/template = anything
maybe what you are describing is like the prior Yaml based input we used to use?
[1] https://github.com/hofstadter-io/hof
[2] https://docs.hofstadter.io/getting-started/code-generation/#...
[1] https://github.com/mikefarah/yq
This shows a TUI I've been working on to grok, munge, and ETL config. It leverages CUE, but it's not required
You tweak a line, push, wait, check if it worked, rinse, repeat. It's even more infuriating when YAML-consuming tools silently ignore extra fields. You get some dash or colon wrong, and then it just doesn't work, and it won't tell you why.
I know of a new bunch of new tools which all look interesting. I feel like most of the time, they miss an easy way to parse using your programming language of choice, and you end up having to convert from cue -> json -> load in python.
- nickel-lang
- cue-lang
- kcl-lang
- dhall-lang
Not sure if this addresses the issue you describe. I'm certainly doing what you do to get CUE into Python, while Go has that native feel for CUE
I think it's another example of the different ways people understand (I don't want to call it "reading") code: "textually" or "visually".
I suspect the same subset of people find lisp, coffescript or yaml readable, with the same drive of removing everything that isn't "words" from the code (useless noise!). The punctuation doesn't let them read the code as a text, I guess? and they only build the structure of the code in their heads after a "linear pass" through the code?
While myself and others like me are very happy with all the punctuation that makes the structure jump out to us at literal first sight. I build the structure first in my head and fill in the "words" later.
I made it sound all neutral-like and all, but it's not, my way is certainly much better. Learn to grok code visually, it's better.
It's not like anyone if forcing you to use one format. For example, K8s spec can be in yaml, json or jsonnet. Choose what feels most natural, instead of sticking with the default and complaining. Conversion between formats is cheap anyway.
> ps. By design, this website is as usable as YAML.
Yes, XML is verbose and complicated, but all other formats I tried, be it Json, YAML, Toml, for me they all have nasty gotchas and/or inconveniences.
I’m not saying that’s a good argument for using YAML, but IMO it should be a consideration for any data format that’s not binary.
The worst data formats are “not binary but still unreadable.” Apple Cocoa XML serialization format, I’m looking at you.
Markdown is a markup format that looks nice to humans, but neither XML nor HTML are particularly nice. Some XML-based formats like Microsoft Office documents are downright incomprehensible without specialized tools.
What's hard to get? It's a data interchange format whose primary usecase is to store data structures intended to be read and edited by humans, using plain old text editors.
Your reply is illogical. GP only identified a false argument. They didn’t say there was no valid argument on the page. There is no straw man.
In docker-compose YAML files, when using a container port lower than 60, because YAML parses numbers in the format xx:yy as a base-60 value.
Like the syntax (it doesn't turn non-techies off from changing some config values), but aren't a fan of all the magic whistles that can shoot you in the foot if you don't have near-encyclopedic knowledge of them.
The spec is too big for something that's supposed to just live in some of our configuration files.
strictyaml is an attempt at tightening things further. But a lot of systems that use "yaml" don't implement any spec, because they write their own parser. For example IIRC gitlab ci doesn't support anchors but has their own code reuse construct.
And then there are all of the string templating extensions that projects like Ansible and Helm employ. These in my opinion are far worse than anchors and should be eschewed in favor of a non-static configuration like jsonnet.
I reckon the only thing it's missing to be truly accessible to non-techies is that string values still need to be quoted, i.e. you can't have:
key: this is my value
(I'm definitely not saying it would be a good idea to allow quotes to be dropped, just that that's the only potential stumbling block I see for non-techies.)
Edit to add: oh, hmm, I guess trailing commas are fiddly too. Possibly I want some even laxer variant of JSON that lets you use just newlines! :P
JSON5 is elegant in that it's purely a subset of JavaScript (exactly as the original JSON is). But in practice that doesn't really gain you much besides a familiar syntax, and Hjson looks simple enough that the slight differences from JS shouldn't be a problem.
The real problem is how to persuade people to use something like this. For the few cases where JSON isn't already entrenched, YAML and TOML and the like have already salted the earth.
I prefer explicitly marking strings. If I try to write a number, I want confidence that I'll get either a number or a parse error. (Though that doesn't necessarily mean quoting the string, other methods could work.)
Needing to deal with escaping can be a bit of an issue, though. The best option I've seen for that is [[the syntax for long quotes in lua]].
Not affiliated. Just want to see the project succeed.
The solution is uncannily simple tho, fuck YAML, just generate it from Dhall; enjoy the subsequent bliss!
I wrote about it here: https://misc.l3m.in/txt/json.txt
Once spent hours to figure out why something failed coz the error messages were so cryptic and it turned out only two extra spaces...
The company I work for had a bug driven by the underscores-in-numbers and scientific notation functionality (`20230101000000_e111111`, a timestamp underscore a git short hash, was parsed as a huge number rather than a string). The serialization library from one language did not implement those features and so did not quote the value in its output, but the deserialization library in the other did and would parse it as a number. This eventually resulted in it becoming null (not sure why, maybe it was too large for the int type in the target language?) but even if it hadn't been we then format it into a URL (to download an artifact) so the fact that our YAML libraries disagree would cause the string value to change and break the download.
The YAML standard is too big, resulting in only partial implementations, and the disagreements can result in unexpected value changes. With no handcrafting whatsoever.
An upvote just for this comment! :)
But I think a lot of the criticism around YAML misses the mark. YAML is not excessively overused as configuration language. It is not dominant like XML was back in its heyday. TOML has a pretty strong mindshare, and many projects are still using JSON or XML. I would pick TOML over YAML any day for this usage, but I still think YAML beats XML and JSON (just think about comments and terrible merge resolution whenever you add an item to an array or an object).
But YAML does reign supreme in the world of DevOps-oriented DSLs. YAML is more suited for DSL compared to alternatives, like TOML, JSON, JSON5 or XML:
- YAML is the least verbose of all alternatives (especially XML, but even JSON5 and TOML).
- YAML requires the least of amount of "syntax noise" on top of your DSL. The "syntax noise" is mostly limited to indentation, colons, dashes (for arrays), indented text block markers and occasionally quotation marks. JSON, JSON5 and TOML require quoting all string values and explicitly marking arrays and object boundaries, which make the DSL seem less fluent. XML is even worse.
- YAML supports indenting multi-line strings, so you can easily embed other formats. This makes adding markdown descriptions (in Swagger/OpenAPI) or embedded shell scripts (in YAML-based CI/CD DSLs) a breeze.
- YAML syntax is hierarchical. The same is true for JSON and XML, but not for TOML. TOML syntax only has two fixed and assymetrical tiers of hierarchy: sections and key-value pairs. Hierarchy can be achieved while parsing, by grouping sections hierarchically, but this is not reflected in the syntax, and this property makes TOML ill-suited for DSLs.
Of course, TOML was never meant to be used for DSLs - it's was designed as a configuration language, just as JSON was designed to be a simple data exchange format and XML was designed as a document markup language. But if you had to choose any of the format above to base your DSL on, YAML seems like the natural choice.
What is the best alternative to YAML then? Probably writing your own parser and removing all unnecessary cruft that you keep to make your DSL fit the YAML straitjacket. And that's the real problem, and the real reason why YAML is overused: parsing YAML is easy, but writing your own custom parser is hard.
Sure, most languages have at least one easy to use library that lets you implement a basic parser based on PEG or parser combinatorics quite easily. But even then you have to deal with all the fun things like: ambiguities (or lack thereof[1]), the limitations of whatever parsing technique you've chosen, tokenizing newlines and indents and parsing a token tree that is still not as clean and easy to parse as YAML.
YAML is still two or three order of magnitudes easier than even writing the simplest parser, so most tool writers pick up it for writing their DSL. This is the age-old "worse is better" principle. It is faster and easier to release and iterate on YAML-based tooling, so most projects pick up YAML and the ones that pick up YAML tend to both ship and iterate faster, and then go ahead to capture the market.
> IMO if there was something that was substantially better, we would see projects switching to it in a heartbeat.
Maybe not in a heartbeat, but I do think most of the "YAML alternatives" out there didn't even try to address DSLs. Maybe we should admit defeat on the make-your-own-parser front and design proper DSL carrier language that can be at least somewhat better than YAML.
[1] https://jeffreykegler.github.io/Ocean-of-Awareness-blog/indi...
How do you roll back a bad config ?
It's like using an XML file for what a txt file could do.
It demands frankly unnecessary structure and formatting just to be ingested, when it's all serially-read parameters, anyway.
YAML isn't the only way to implement parameterization. We could use our imaginations and think of a ton of tried-and-true ways to abstract it.
Have you ever done a quick-deploy on a cloud platform? The alternatives just generate all the esoteric stuff for you. Config files generated by guided steps.
for me? json, yaml, dgaf. Yq works as well as jq.
Yaml is so hard to get right, a misplaced dash or indentation in a list and you're screwed but it's still passable, just does something else than expected. It's not really human readable either, it takes a lot of brainpower (at least for me) to understand what belongs together in a list or how things are grouped together. Much more than for instance xml where it's obvious.
Yaml only barely works, because many editors have added support to help you write k8s config. Otherwise it would be impossible.
Yea, you shouldnt put a lot of logic in your configs. yaml doesnt do that. the tooling does. and templates can be simple and easy to read and DRY principles can put you into traps that make your code harder to maintain than it should be.
Sure, and in the end it's all 1's and 0', but that doesn't seem relevant..
>“Norway” being interpreted as “NO” boolean false is something that sounds very weird to me
Agreed, it's truly weird. YAML tries to be helpful and guess what you meant, a trait that is great in many situations, but not in a config language.
I disagree. YAML can't be transcribed 1:1 to JSON.
Here is an example:
&map: ? {[Complex, key]}
: *map:
And fact introduces context sensitivity (flow vs block, plain vs fold/literal) means its perfs will be kneecapped. I'm aware of high perf json/xml able to read GB/s. Not so for YAML.
Can you give me a practical example of the incompatible data structure you’ve described that isn’t reliant on tooling? I really can’t.
Just because you use it for one page docker conf, doesn't mean someone won't use it for 3000 yaml files that need to load in under ten seconds.
Not to mention complexity of the language will reflect onto complexity of the tooling. The more complex writing tooling is, the less likely someone will write it.
Also I hate the term "human readable". JSON is human readable and editable. Sure you might have problems with editing it, but my work colleague can read binary blobs. That doesn't make them binary blobs human readable.
Also, if the CD process is not too dumb the json validate will find the errors before the file enter production which will save you. At my first company they rewrote our ansible inventory files in json because a yaml uncaught indentation mistake made a firewall open by default, silently.
Using a restricted subset of both could work, I suppose. But seems a lot of hassle over a minor issue.
Norway.
The first reaction I get is usually "What, JavaScript!?". Here is why its better than it looks like.
Deno easily runs TypeScript without a compile step. TypeScript is a very mature, developer friendly language that was designed to model the super complicated types often seen in JS. This includes unions and intersections which help you model complex rules between optional properties, as well as template literal types which can help you restrict string constants. As it happens, those same types of objects are present in our configurations.
TypeScript is also flexible about how much you'd like to model. Do you want only properties with really nice autocomplete with docs from the language server? Sure we can do just that. Do you want to only allow strings that look like a time duration for that property? Can be done too with template literal types. You choose where to invest your energy.
Building abstractions on top of IaC is seen as painful and obscure. TypeScript has tools to help you avoid that, such as api-extractor: https://api-extractor.com/ - it can enforce that all your function abstractions are documented and it can generate that documentation for you.
The larger ecosystem also comes with a lot of ready-made codegen tools that can help, from small modules such as json-schema-to-typescript (https://www.npmjs.com/package/json-schema-to-typescript) to larger mature projects such as jsii and https://github.com/cdklabs/json2jsii . They can be used to build the tooling to import things like CRDs and other external schemas.
What about running arbitrary code, launching rockets, turing completness? This is where Deno comes in, with its permissions model (https://docs.deno.com/runtime/manual/basics/permissions). You can allow only a subset of commands (lets say, `helm` and `kustomize`, while you're migrating away from them), a subset of (writable) directories, accessible network hosts - or none at all.
What about the pains of managing JS modules? Deno lets you import files directly from URLs. It also allows you to set private tokens in env vars to ensure the imports succeed: https://docs.deno.com/runtime/manual/basics/modules/private - as a result, you can manage your IaC libraries the way that makes sense to you, without dealing with the unwieldy package managers of the node ecosystem.
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.
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."
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.
- 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,…
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.
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.
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.
> 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.
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.
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?
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.
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.
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
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.
If I was free to use any format, I would always go for XML instead.
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.
S-expressions curiously omitted from the list of textual tree formats that are not perfect. Hmm... :-D
Do we have mods on HN that can get rid of these dupe posts?
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...
>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
Not really; this website hasn’t been updated since 2018.
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.
Switching from YAML 1.1 (2005) to YAML 1.2 (2009) for that reason makes perfect sense, I think.
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.
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.
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.
I was all onboard the yaml hype train until I finally started using it more for the daily job. json > * in my stogy brain.
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...
There are two types of programing languages, those that everybody hates, and those that nobody uses.
JSON is so popular probably because you _can't_ improve it! It is too entrenched.
What problem do you see in adopting Dhall?
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.
It's amazing what you can do with it, given the appropriate platform. Some people even managed to implement a decent editor using elisp.
The upside is that sometimes we manage to do the opposite. Perhaps it's worth it.
Like I have a fu* choice with Gitlab ci enforced onto me by organization.
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.
YAML is good for human readable configuration, with some notable caveats. But its terrible for being a secret programming language where the only way to execute it is to put in a PR request, commit to a live branch etc.
Bingo, people keep implementing incredibly complex DSLs that are based on YAML, and users keep shoving more complexity into that YAML since it's the only tool they have to interface with $THING, and all of a sudden nobody can comprehend what is actually going on just by reading it.
It's not a problem of YAML per se (another format would just have its own footguns / pain points), it's a risk with any DSL: you can create something so complex that it's actually less clear and harder to manage than it would have been with a normal programming language from the start.
code monkeys do that.
I like YAML for exactly what you describe but people abuse it then complain it sucks.
No 1000 ways to say true/false. No 1000 ways to have strings.
No significant whitespace in config files (also helps out with the 1000 types of YAML strings).
Etc.
A subset of YAML that drops all that garbage.
And yeah, the CI/CD stuff should also use... a sandboxed programming language.
I think Lua and Tcl can remove functions and language constructs in a sandboxed enviroment. Pick one of those, or improve it slightly (make Lua 0-index based if you so care), and then use that.
It's not a problem that $CI YAML configs have multiple ways to encode strings and need indentation. Yes, "no" issue sucks a bit, but it's not that huge, just a minor papercut. The giant root issue is that YAML is simply not an appropriate format for this kind of stuff. People are writing more and more complex programs (modern CI pipeline is a program*) in it, when it's not a [suitable] programming language.
And it's not suitable not because of whitespace. Syntax doesn't matter that much (unless you're a junior developer first time seeing APL - just kidding, of course), it's all about the semantics. YAML was never meant for writing programs, it doesn't have necessary constructs to support those (but people are inventing DSLs on top of it, and it looks and feels awful).
Similar logic applies to some orchestration systems, some IaaC stuff and other areas where YAML is not a great fit because systems either "outgrew" simple configurations to something else (like programs, but not always) or YAML was a bad fit from the very beginning. CI is just the most obvious example.
*) It made sense when CIs were simple, and those YAML files were configuration snippets rather than programs. Just like Makefile makes a lot of sense, when it's able to do all you need. But CI grew more and more complicated.
"You know what would be great? A conditional statement of some kind. That would be super handy."
Not for me it's not.
# Doing the same thing with different CI providers
Guess what: this is just an interface, everyone does everything differently in every language/format no matter what.
This is Reddit-level junk humor made by someone with more arrogance than sense. I flagged it.
I'm not sure my experience is typical, but the creator of this page probably spent more time dealing with YAML building said page more than I spent working with YAML for MY ENTIRE LIFE.
I get it, the language has its flows, and they are apparent even with my limited exposure to it, but I don't think YAML would constitute the major part of anybody's workday. People probably spend more time and energy hating on YAML than actually working with it.
Kubernetes definitions, Helm, Ansible, a lot of popular CI tools use it.
Maybe you and I haven't been bitten personally by YAML idiosincracies yet, but just learning about examples like the "Norway problem" and the "negative GPS coordinates bug"—and thinking how frustrating must have been to figure those out in the first place—makes me shudder.
Kubernetes stuff.
Many, many other CI/CD tools.
This is the reason so many people don't like YAML. They don't know how to use it right, and they keep fucking it up, getting pissed off, and not learning their lesson.
Don't write YAML by hand and it works fine. And maybe read the spec...
While we're on the subject - Did you know you don't have to pick from 3 existing formats? You are allowed to make your own new configuration formats. And you are allowed to make them not be some perfect universal solution for all configuration needs for all programs.
Back in the day, every program invented its own configuration format, with features designed just for what that one program needed to do. They were ugly and not based on any kind of "principles" or "best practice" or trendy bullshit found on a social media site for nerds. It was just whatever the user found easiest that worked. No standards, just a wonky configuration that worked great for that one program. And guess what? All those weird formats, they are still around today, because the programs are still around, because they are useful and work.
Get off of HN and make something unique that you find useful. Don't ask people on here if it's good, just use it. If it works for you, it's good enough.
It looks easier than JSON to write by hand. JSON at least makes it known that you’ll have a better time generating it, that writing it.
It’s like those doors that open by pushing them. Some open both ways, some have a handle to grab and open it to you, some have a plate for you to push on.
And some (like YAML) have a plate on the side you need to pull, and a handle on the side you need to push.
No, it was intended to be an alternative to XML. But it was the renamed to YAML Ain't a Markup Language, because it's really intended to be used for data, not human-centric markup.
YAML uses hard data typing, and types are inferred (though can be explicit). When a program serializes data, it does not add the explicit types. Therefore for a human to edit the file, they would need to have the entire YAML parser semantics in their brain, or add the explicit types, and hope the YAML parser they are using will re-serialize the explicit types (most are poorly implemented and won't).
Therefore it is virtually impossible for a human to write YAML correctly by hand. Its only reliable use is as a data language for programs to serialize data. It just happens to be easy to read.