Live data from Hacker News

Why are we templating YAML? (2019)

leebriggs.co.uk

211–220 of 667 posts

Re: Why are we templating YAML? (2019)

#211
If you're using Helm to deploy your own apps, I feel that's a code smell. I'll add jsonnet for your own apps to the that list.

Just use dumb YAML, maybe kustomize if you really need, but if that's not sufficient, consider that a sign that you're not carving the wood the way it's telling you to.

Any form of templating for creating your own application manifest is another moving part that allows for new and fun errors, and the further away your source manifest is from the deployed result, the harder it is to debug.

If you really want to append a certain set of annotations to each and every pod in a cluster, instead of using shared templates (and enforcing their usage), there's other approaches in K8s for these kinds of use cases, that you have a lot more control over.

Re: Why are we templating YAML? (2019)

#212

Earlier quoted context omitted.

The biggest issue I have with Yaml is that they forbid tabs. Their argument is that tabs are shown differently in every editor which is actually something I like. When you're looking for something deeply nested you can reduce the tab distance a bit, when that's not needed you can increase it to improve visibility of nesting levels. And forbidding it makes a one-keystroke action a two or four one. I really don't under…

> And forbidding it makes a one-keystroke action a two or four one. You can’t be serious

Not everyone wants a bloated and buggy IDE to write their code for them.

Re: Why are we templating YAML? (2019)

#213
post #75

Serendipity strikes as I'm implementing an emrichen interpreter in golang after getting too annoyed about templating YAML as a string. The reasons I like yaml is that I can see the tree structure directly, and to my lisp brain it is extremely easy to read. Furthermore, in our age of LLMs, I find LLMs to be able to generate "correct" YAML more easily than JSON, since the tree depth is encoded in every line, and doesn'…

I totally agree with you on LLM usage. I have recently switched from JSON to YAML for requests and replies from LLMs (GPT-4 specifically) and I find it much better: fewer tokens used, more readable if you are looking at the http requests and responses and you can parse it on the fly in streaming responses. The last point lets you do visual updates for the user, which is pretty important if you need to wait 1+ minutes…

I'd be very curious to know what kind of previews/streaming YAML applications you are building with LLMs. I have building a v0.dev kind of thing with streaming update on my TODO list.

Re: Why are we templating YAML? (2019)

#214

To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel ( https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... ). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”,…

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

TOML has the inline table syntax with curlies, like JSON, and inline array syntax with brackets, also like JSON. It could support nesting pretty well.

Sadly, it doesn't support line breaks in the inline table syntax, so using inline tables for nesting is a PITA; inline tables are pretty much unusable for anything which doesn't fit within like 80-100 characters. Inline arrays can contain newlines however, so deeply nested arrays works well.

Newlines in inline tables will be coming in TOML 1.1, which will make TOML much better for deeply nested structures. Unfortunately, there will probably be many years until 1.1 is both actually released and well supported across the ecosystem.

And of course, inline tables can't be at the top level of the document, so TOML might still not be the best way to represent a single deelpy nested structure.

Re: Why are we templating YAML? (2019)

#216
post #8

I think YAML is a good pick for non-developers / content creators. The front matter section in Markdown files is a good example. Or is there a better, human-friendly alternative?

Why something so complex for front matter? Isn't it typically just a few key/value pairs?

Re: Why are we templating YAML? (2019)

#217

Earlier quoted context omitted.

> I don’t understand why people are still using it It's a good comaparator, there are indeed a lot of similarities, but I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. It's more like Python than Coffeescript really: it's not just about simplicity & brevity, it's about terminators. Whitespace-dependent languages are often a pain to format / p…

> I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. When Coffeescript was invented, it was an advancement on top of the awful Javascript standards at the time. It never went anywhere because Javascript caught up, but Coffeescript had a good reason for existing. Today, Coffeescript is a remnant of old frontends that nobody has bothered transpil…

> it was an advancement

That was certainly the selling point. I never saw any advancements in it - the features were aesthetic syntactic sugar.

Re: Why are we templating YAML? (2019)

#218

Earlier quoted context omitted.

> And forbidding it makes a one-keystroke action a two or four one. You can’t be serious

Not everyone wants a bloated and buggy IDE to write their code for them.

Almost every text editor has support for tabs-as-spaces.

I haven't used an IDE in years.

Re: Why are we templating YAML? (2019)

#219
post #17

Earlier quoted context omitted.

In some places working with Kubernetes, people unironically use the term "YAML engineer".

I've seen memes where SREs complain they have just become YAML engineers. :(

I've been there. Not YAML specifically, but basically just configuration (XML, JSON, properties, ...) for some proprietary systems without any good documentation or support available. "It's easy, just do/insert X", half a year and dozens of meetings and experts later, it was indeed not just X. Meanwhile I could've build everything myself from scratch or with common open-source solutions.

Re: Why are we templating YAML? (2019)

#220
post #72

I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…

> I heard you liked configuration languages, so I made this configuration language for your configuration language generation scripts. It supports templates, of course.
Post reply on HN