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

601–610 of 667 posts

Re: Why are we templating YAML? (2019)

#601

Post by smaudet »

PH95VuimJjqBqy wrote: post #547
smaudet wrote: post #522

Earlier quoted context omitted.

> you don't have a configuration format but a serialization format While I better appreciate what you are saying now (you don't have a solution), the only appreciable difference between "config" and "serialization" is that of write frequency - config is seldom updated, serialization is often updated. Otherwise, they are the same problem with the same solution - you might provision resources differently based upon "dy…

I'm going to submit that if you think configuration and serialization are the same problem it's time to step back and re-evaluate what you're doing, which is really the authors point. As Joel Spoelsky said years ago, if you abstract far enough up everything starts to look the same but that doesn't make it so https://www.joelonsoftware.com/2008/05/01/architecture-astro... At the end of the day you could claim that all…

> if you think configuration and serialization are the same problem

Except that's precisely not the point...rather the formats they are written in are the same, they are indistinguishable.

Reductio-ad-absurdum, if all data exchange is the same then there is no benefit to any format, just write binary strings with null-terminal characters. Except for the many downsides to that approach, so it turns out that they are not the same...

And never-the-less, if all configuration were not serialization, there would be not be any need to be generating config via a different language per the OPs' post...

So we find the similarities between configuration and serialization to be more pertinent than their dissimilarities wrt to format.

INI is absurd for any complex configuration, "just use a turing complete language" is as good an answer as deciding to write binary data randomly...

Re: Why are we templating YAML? (2019)

#602

Post by smaudet »

naniwaduni wrote: post #261
BenjiWiebe wrote: post #238

Earlier quoted context omitted.

1 vs 0 is another typo of Boolean values with opposite meanings, in quite a few languages.

Worse, the ability to typo 9 in some languages for 0 and flip your boolean when it should be a type error just seems like a misdesign.

Lets hear it for true/false, and triply enforced booleans (variables represented by three or more memory locations https://en.wikipedia.org/wiki/Triple_modular_redundancy) !

Re: Why are we templating YAML? (2019)

#603

Post by Hackbraten »

thfuran wrote: post #275
Hackbraten wrote: post #23

Earlier quoted context omitted.

Java properties files are a mess. They still require Windows encoding (ISO-8859-1), which is incompatible with UTF-8.

Only if you're still using java 8.

That's a common misconception.

Look at the documentation [0] or at the OpenJDK code. Both assume ISO-8859-1, unless you're dealing with a special case where resource bundles are involved.

[0]: https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

Re: Why are we templating YAML? (2019)

#604

Post by Hackbraten »

int_19h wrote: post #556
Hackbraten wrote: post #23

Earlier quoted context omitted.

Java properties files are a mess. They still require Windows encoding (ISO-8859-1), which is incompatible with UTF-8.

ISO-8859-1 is Latin-1, there's nothing specifically "Windows" about it.

You're correct.

Re: Why are we templating YAML? (2019)

#605

Post by SergeAx »

bilalq wrote: post #404

I'm completely done with configs written in YAML. Easily the worst part of Github Actions, even worse than the reliability. When I see some cool tool require a YAML file for config, I immediately get hit with a wave of apprehension. These same feelings extend to other proprietary config languages like HCL for Terraform, ASL for AWS Step Functions, etc. It's fine that you want a declarative API, but let me generate my…

> Config declared in and generated by code has been a superior experience.

And here we are at the point in time when people are plainly forgotten about compiled programming languages.

Re: Why are we templating YAML? (2019)

#606

Post by vidarh »

fatherzine wrote: post #371
vidarh wrote: post #270

Earlier quoted context omitted.

The worst thing with Helm charts is not the YAML, or even the text replace botch-jobs, but that they seem to think that a Go stacktrace is reasonable error reporting. I don't think I've ever worked with a tool with such awfully useless error messages. But I agree, it'd be better if the template expansion was actually structural and not just text. The huge amount of "| indent 8" etc. in Helm charts is such a stench th…

Unlikely it will ever get better. First to market with a prototype tool, gains market share and momentum. Eventually the enthusiasm fades off and people start hating it, for good and sometimes bad reasons. Yet users are stuck because change is expensive and risky. The team is stuck because any change risks becoming the straw that broke the camel's back, possibly cascading through the user population. Story of our you…

I think you're part right in that I don't think they will make any backwards incompatible changes. But they could still make things a lot better in two simple ways:

* Fix error reporting. Nobody is doing anything that relies on the current error reporting anyway because it's near useless.

* Add a slight templating change that means "after this parses as valid YAML, expand this bit, and check that the expansion is itself valid YAML before merging it in" with options to either replace the node, or merge in adjacent (the latter to insert in lists etc). You can do that without backwards incompatible changes by making a syntax change that still uses the go {{ ... }} blocks, but that starts with a directive they can make simply expand to a new template processing directive in the first pass. Then just add a second pass that operates on a parse tree (I've just written a template expansion mechanism that works on json/yaml parse trees, in fact; if we didn't need Helm charts primarily for distribution to partners that I don't want to make use a custom deployment tool, I'd be tempted to replace our Helm charts with an expansion of that.

Better error reporting and being able to avoid the incessant "| indent .." blocks and ensuring the output either generates valid yaml or can "contain" the error report to the generated sub-block would make it so much easier to use.

Re: Why are we templating YAML? (2019)

#607

Post by Draiken »

linuxftw wrote: post #568
awesomeMilou wrote: post #457

Earlier quoted context omitted.

So why is there this massive ecosystem around not writing modules then? RedHat invented automation controller just so they didn't have to implement proper error handling with Ansible.

The 'not writing modules' approach is for people that aren't comfortable writing code. I think most capable users for non-trivial things should write custom modules a lot of the time.

That's not how Ansible is meant to be used by default though. Modules are, in general, meant to be generic.

I bet you if I started writing modules for everything in most companies, people would complain. Unfortunately defaults matter.

Re: Why are we templating YAML? (2019)

#608

Post by usrbinbash »

eviks wrote: post #372
usrbinbash wrote: post #351

Earlier quoted context omitted.

If people absolutely want those, they can use TOML, which supports single line and inline comments. Given a choice, I'd even opt XML over YAML.

That's fine, you can pick whatever XML ugliness you like, I was just pointing out that you can't solve the basic fail of JSON with comments by making them data

> I was just pointing out that you can't

No, you were pointing out that some people won't like that solution. Which is completely fine. And yes, that solution is ugly as hell, and it is a dirty hack, and I don't recommend actually doing that if there is a better way (like TOML).

But it does work.

https://www.youtube.com/watch?v=C5kGCwJ25Yc

Re: Why are we templating YAML? (2019)

#609

Post by BiteCode_dev »

arianvanp wrote: post #87
planede wrote: post #70

Earlier quoted context omitted.

How does it compare to dhall?

Dhall's lack of any form of type inference makes it very verbose and difficult to refactor in my opinion. (I'm the author of dhall-kubernetes and never ended up using it in production; funnily enough). Dhall is also extremely slow. We had kubernetes manifests that took _minutes_ to type-check. Cue is basically instant. This matters a lot to me. I find cue very ergonomic. Also it treating both types and values as valu…

Functions are a nice to have, but:

- It tends to make things less declarative.

- You lose locality of behavior, which is very useful in configuration.

Also, nickel doesn't support injecting data into the nickel file, so external program can't set variables, query a database and pass the result to the conf file, etc.

Re: Why are we templating YAML? (2019)

#610

Post by BiteCode_dev »

ParetoOptimal wrote: post #599
arianvanp wrote: post #87

Earlier quoted context omitted.

Dhall's lack of any form of type inference makes it very verbose and difficult to refactor in my opinion. (I'm the author of dhall-kubernetes and never ended up using it in production; funnily enough). Dhall is also extremely slow. We had kubernetes manifests that took _minutes_ to type-check. Cue is basically instant. This matters a lot to me. I find cue very ergonomic. Also it treating both types and values as valu…

> Dhall is also extremely slow. We had kubernetes manifests that took _minutes_ to type-check. Cue is basically instant. Everyone wants type-safety, but no one wants to wait for the type-checker :) Maybe in this case dhall with type checks equivalent to dhall would be slower, but I notice in many places people say "strong type-checking is valuable" while still expecting similar compile times as languages with weaker…

People always undervalue the beauty of a short feedback loop until it's taken away from them.

And even then, they won't exactly pin point the problem, rather express their general frustration, without realizing that the dynamic system they used had indeed some great properties and were not popular for no reason.

Post reply on HN