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

121–130 of 667 posts

Re: Why are we templating YAML? (2019)

#121

Post by SOLAR_FIELDS »

krapp wrote: post #97
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…

You shouldn't need the full complexity and power of a Turing complete programming language to do config. The point of config is to describe a state, it's just data. You don't need an application within an application to describe state. Inevitably, the path of just using a programming language for config leads to your config becoming more and more complex until it inevitably needs its own config, etc. You wind up with…

Yeah, YAML is good at declarative things. It’s when you start using it imperatively eg CI/CD is when it really starts to get ugly.

Re: Why are we templating YAML? (2019)

#122

Post by torginus »

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…

Like with Python, any competent text editor will take care of this for you, I've never encountered this issue before.

Re: Why are we templating YAML? (2019)

#124

Post by TheFuzzball »

Havoc wrote: post #108
TheFuzzball wrote: post #73

Earlier quoted context omitted.

I think custom code is to be expected, and making it maintainable is what's important. > everything should be made as simple as possible, but no simpler. Helm et al made it simpler than it was, IMO.

Everyone hand rolling code does not seem like an improvement over tools like helm even if it’s yaml

No, obviously not, and that's not what I've suggested.

Re: Why are we templating YAML? (2019)

#125

Post by gtirloni »

I love YAML and I curse it every single day that I'm working with Helm charts.

People ask me what I'd use to deploy apps on Kubernetes and I say I hate Helm and would still use it for a single reason: everybody is using it, I don't want to create a snowflake infrastructure that only I understand.

Still, back in the day I thought jsonnet would win this battle but here we are, cursing Helm and templates. That's the power of upstream decisions.

Re: Why are we templating YAML? (2019)

#126

Post by Draiken »

krapp wrote: post #97
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…

You shouldn't need the full complexity and power of a Turing complete programming language to do config. The point of config is to describe a state, it's just data. You don't need an application within an application to describe state. Inevitably, the path of just using a programming language for config leads to your config becoming more and more complex until it inevitably needs its own config, etc. You wind up with…

The complexity is already there. If you only need static state like you say, then YAML/JSON/whatever is fine. But that's not what happens as software grows.

You need data that is different depending on environments, clouds, teams, etc. This complexity will still exist if you use YAML, it'll just be a ridiculous mess where you can break your scripts because you have an extra space in the YAML or added an incorrect `True` somewhere.

Complexity growth is inevitable. What is definitely avoidable is shoving concepts that in fact describe a "business" rule (maybe operational rule is a better name?) in unreadable templates.

Rules like: a deployment needs add these things when in production, or change those when in staging, etc exist whether they are hidden behind shitty Go templates or they are structured inside of a class/struct, a method with a descriptive name, etc.

The only downside is that you need to understand some basics of programming. But for me that's not a downside at all, since it's a much more useful skill than only knowing how to stitch Go templates together.

Re: Why are we templating YAML? (2019)

#127

Post by cannonpalms »

anentropic wrote: post #42
Leo_Verto wrote: post #15

Earlier quoted context omitted.

The fact that it's a purely functional programming language with lazy evaluation is really powerful but steepens the learning curve for devs who haven't worked with functional languages. The stdlib is also pretty sparse, missing some commonly required functions.

> The fact that it's a purely functional programming language with lazy evaluation is really powerful but steepens the learning curve for devs who haven't worked with functional languages. does it really though? what part do they struggle with?

IME engineers struggle with folds most.

Re: Why are we templating YAML? (2019)

#128

Post by SOLAR_FIELDS »

MrBuddyCasino wrote: post #56
ManBeardPc wrote: post #4

Worse yet, in some places (CI/CD) YAML becomes nearly a programming language. A very verbose, unintuitive, badly specified and vendor-specific one as well.

Even worse, every generation repeats this mistake. I‘m not sure S-Expressions are the answer, but Terraform HCL should never have been invented.

I was just telling a colleague today that HCL is great until you need to do a loop. A lot of parallels to this YAML discussion

Re: Why are we templating YAML? (2019)

#129

Post by bayindirh »

chx wrote: post #111
bayindirh wrote: post #77

Earlier quoted context omitted.

TOML is just an .ini file plus some syntactic and computing sugar. I can argue that TOML is actually way older than it is.

1. I am unaware of a standardized .ini format 2. The native types in TOML are useful.

This is an .ini:

    [section]
    option=value it the way you want it.
    ; And these are comments. That's all.
I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things.

I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them. It's same for INI.

You can have "native types" in .ini as well. The difference is you'll be handling them explicitly yourself, and you should do that in defensive programming anway. A config file is a stream of input to your code, and if you don't guard it yourself, you agree what that entails.

Re: Why are we templating YAML? (2019)

#130

Post by resters »

In my view, the presence of YAML templating is a red flag in any codebase or system.

YAML got its popularity with the advent of Ruby on Rails, largely due to the simplicity of the database.yml file as an aid in database connection string abstraction that felt extremely clean to Java programmers who were used to complicated XML files full of DSN names and connection string peculiarities.

The evolution of the database.yml file into something arguably as complex as the thing it was intended to replace is described in the article below:

https://dev.to/andreimaxim/the-rails-databaseyml-file-4dm9

Post reply on HN