Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why are we templating YAML? (2019)

leebriggs.co.uk

Post reply on HN
Print view View original

191–200 of 667 posts

Re: Why are we templating YAML? (2019)

#191

Post by andix »

Draiken wrote: 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…

Helm would probably benefit from something like JSX for YAML/JSON. Just being able to script a chart instead of this templating hell.

Re: Why are we templating YAML? (2019)

#192

Post by jeroenhd »

mark_and_sweep wrote: post #171
Draiken wrote: 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…

Agreed, and I almost feel silly for pointing this out, but for writing JSON (JavaScript Object Notation), I'd recommend using JavaScript...

For JSON I'd stick with Typescript to be honest. You end up executing Javascript and producing Javascript-native objects, but the typing in Typescript to ensure the objects you produce are actually valid will save a lot of debugging.

Re: Why are we templating YAML? (2019)

#193

Post by orwin »

reissbaker wrote: post #172

I think Steve Yegge got it right when he wrote: I know, I know — everyone raves about the power of separating your code and your data . . . But it's [not] what you really want, or all the creepy half-languages wouldn't all evolve towards being Turing-complete, would they? https://sites.google.com/site/steveyegge2/the-emacs-problem Templating YAML is the same, but... Honestly, Jsonnet is too. If you're going to genera…

Does it mean that Lisps 'code is data' is the right idea in the end?

Re: Why are we templating YAML? (2019)

#194

Post by michaelmior »

wkat4242 wrote: post #117
torginus wrote: post #109

Earlier quoted context omitted.

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…

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.

The majority of editors can be configured to use tab to insert the appropriate number of spaces. Many will automatically detect the correct configuration.

Re: Why are we templating YAML? (2019)

#195

Post by rad_gruchalski »

aeyes wrote: post #186
rad_gruchalski wrote: post #110

Earlier quoted context omitted.

Helm is another can of hot garbage. Impossible to vendor without hitting name collisions, can configure only what’s templated. Jsonnet is the way to go with generated helm manifests transformed later. Kustomize with its post-renderer hooks is another can of even hotter garbage.

> Impossible to vendor without hitting name collisions What problem exactly are you facing? I can change the name of the chart itself in chart.yaml and if the name of the resources collide I change them with nameOverride/fullnameOverride in the values. All charts have these because they are autogenerated by `helm create`. I vendor all charts and never had this problem.

You just made a copy of a chart. You modified your chart. What I’m missing is helm having some notion of an org in the chart name, like docker does: repo/name:tag, helm only has name and version. Hence you modify your chart.yaml and it should be preferable without having to modify anything.

This is really problematic when a chart pulls dependencies in.

Re: Why are we templating YAML? (2019)

#196

Post by efunnekol »

larve wrote: 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 for the full response

Re: Why are we templating YAML? (2019)

#197

Post by CuriouslyC »

armchairhacker wrote: post #38

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”,…

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

Re: Why are we templating YAML? (2019)

#198

Post by neilwilson »

Obligatory reference to Rubynetes - using Ruby and rspec to generate the YAML files that k8s loves.

[0]: https://www.brightbox.com/blog/2020/02/24/rubynetes-getting-...

[1]: https://www.brightbox.com/blog/2020/02/12/rubynetes-kubernet...

[2]: https://www.brightbox.com/blog/2020/02/17/using-openapi-to-v...

Re: Why are we templating YAML? (2019)

#199

Post by cannonpalms »

spacebanana7 wrote: post #65
simiones wrote: post #35

Earlier quoted context omitted.

Preferably written in assembler, to avoid the extra complexity of a compiler, right? Configuration files have been a common feature of software since OSs exist, basically. They serve a clear and useful purpose, even though they create some problems of their own.

For complex environments like those discussed in the article, there’s unavoidably complicated logic. Code is a good place for logic to live. Compared to yaml, code is more testable, readable and expressible. I should’ve restricted my original comment to the kind of situation in the article where different configs are created for various regions and test environments with optional values. Totally agree configs are use…

Restricting config to static values removes quite a bit of the value of config, in my opinion.

Yes, logic should live in code, but very often that logic needs to behave differently depending on some piece of (inherently variable, not static) configuration.

Random examples (written from the perspective of personified code): - How many threads should I use? - On which port should I serve metrics? - Which retry strategy should I use?

Re: Why are we templating YAML? (2019)

#200

Post by Gare »

transfire wrote: post #184

Is Kubernetes using YAML 1.1 still? Because some of the complaints I hear shouldn’t be an issue with 1.2. Moreover the YAML spec allows for specifying the tags recognized per application. So on two counts, if “on”, “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants , are all boolean literals, it is not YAML’s fault.

Unfortunately, almost everyone is still using YAML 1.1

PyYAML still doesn't support 1.2

Post reply on HN