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

331–340 of 667 posts

Re: Why are we templating YAML? (2019)

#331

Post by wodenokoto »

Like many other things, Azure services can be deployed using JSON. Of course it’s not just json, it’s an entire language of deployment definitions and templating language hidden within json markup.

But next to that, Microsoft came out with bicep, which is a domain specific language for defining resources. It comes with a full language server and is honestly quite nice to use (if only azure services had some sort of reasonable logic to them)

I think k8 and friends need their own biceps.

Re: Why are we templating YAML? (2019)

#332

Post by sethammons »

vidarh wrote: post #270
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 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…

You have an error on line one. Good luck

Re: Why are we templating YAML? (2019)

#333

Post by bqmjjx0kac »

bayindirh wrote: post #246
bqmjjx0kac wrote: post #239

Earlier quoted context omitted.

It is a funny quip, but I wish they'd consider the reformatting. I find using an autoformatter reduces cognitive load while reading and writing.

Yeah, OP is not wrong. I also like neatly formatted code and is way easier to read. I always reformat all my code before all commits. It's just good hygiene. The funny part is the fussing and the answer they get. I'd just autoformat the area of my patch and send in the patch that way, maybe plus some autoformatted blocks here and there, slowly fixing the stuff as I go. If something is too bothersome, first try doing…

Reformat-on-change is also a valid strategy!

I think I've even seen this employed on C++ codebases with clang-format. Conceptually, it's like `git diff | clang-format`, but there are more flags and scripts involved: https://clang.llvm.org/docs/ClangFormat.html#script-for-patc...

Re: Why are we templating YAML? (2019)

#334

Post by dragonwriter »

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

> Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants)?

”on”, ”off”, ”yes”, ”no”, “y”, and ”n”, and case variants thereof, are not boolean literals in YAML since YAML 1.2 (2009).

Re: Why are we templating YAML? (2019)

#335

Post by amath »

sethammons wrote: post #332
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…

You have an error on line one. Good luck

Ah, this had me laughing.

Re: Why are we templating YAML? (2019)

#336

Post by maximilianburke »

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

I wonder if we would even be using YAML or TOML to the degree we are now if JSON had support for trailing commas and comments.

Re: Why are we templating YAML? (2019)

#337

Post by lantry »

gregwebs wrote: post #39

We are switching to cuelang [1]. IMHO it is better designed than Jsonette. Since Kubeenetes already has state reconciliation, the only thing missing in this setup is deletion. But that can now be accomplished with the prune feature. [2] [1] https://cuelang.org/docs/integrations/k8s/ [2] https://kubernetes.io/blog/2023/05/09/introducing-kubectl-ap...

I can second cuelang. We started using it at work and it's so nice. Some of the error messages are a little hard to decipher, but that's acceptable because it catches so many errors up front. The few times I have to write yaml directly, it now feels so tedious in comparison.

Re: Why are we templating YAML? (2019)

#338

Post by eviks »

usrbinbash wrote: post #326

The problem is very specifically the fact that YAML, as a config language, sucks. I have no idea why people started using it. "bUt jSOn dOeSn'T HaVe cOmMenTS" ... oh gimme a break! You want a comment in JSON? { "//": "This is a comment explaining key1.", "key1": "value1", "//": "This is a comment explaining key2.", "key2": "value2" } There. Not so hard. Writing a config parser that just ignores all keys starting with…

That ugly child doesn't cut it, these are the comments people want:

key1=value1 # this is a proper key1 comment, if you move a line, it stays with key1

key2=value2 # it also doesn't break the table

# and you don't need to write a config parser

# nor modify a syntax highlighter

# nor make sure other people use your comment style

Re: Why are we templating YAML? (2019)

#339

Post by slowmovintarget »

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

Obligatory: https://github.com/edn-format/edn

Re: Why are we templating YAML? (2019)

#340

Post by dragonwriter »

theshrike79 wrote: post #234
bayindirh wrote: post #78

Earlier quoted context omitted.

People balk at XML, but its verbosity plus DTD allows it to pull tricks which you can't do on other things. Well everything has its place, but XML is I think very well suited where you need to serialize complex things to a readable file, and verify it while being it's written and read back .

XML + DTD + XMLSchema had things we're still figuring out to do with YAML ja JSON You could easily generate an UI based on just the DTD and Schema that could be used to fill a perfectly valid XML file. Validating incoming XML was a breeze, just give it to the validator class along with the DTD and Schema and boom, done.

All of that is doable with JSON Schema, though, noy so sonething that we’re still figuring out how to so.
Post reply on HN