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

61–70 of 667 posts

Re: Why are we templating YAML? (2019)

#61

Post by hiAndrewQuinn »

XorNot wrote: post #44
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.

This criticism doesn't pass the sniff test though: your average Haskeller loves to extoll the virtues of using Haskell to implement a DSL for some system which is ultimately just doing the same thing in practice (because they're still not going to write documentation for it, but hey, how hard can it be to figure out it's just...) YAML becomes a programming language because vendors need a DSL for their system, and the…

Hey now. Your average Haskeller would simply recommend you replace YAML with Dhall.

https://dhall-lang.org/

Re: Why are we templating YAML? (2019)

#62

Post by bencelaszlo »

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)?

Norway is also "False".

Re: Why are we templating YAML? (2019)

#64

Post by berkes »

difosfor wrote: post #31

Wouldn't it be a better idea to use an existing programming language instead of cooking up numerous half baked templating languages?

Yes.

Except you then have to sensor that programming language severely. Maybe you can accept some endless loop, but you probably don't want the CI orchestrator to start mining Monero, instead of bootstrapping and configging servers and services.

A solution to that sensorship might be a very limited WASM runtime: one that offers a very few API's, has severely limited resources and timeouts and such. So people can write their orchestration in Python, Javascript or Rust or even Brainfuck if they want, but what that orchestration can do, and for how long it can do that, and how much memory, space and so on it gets, all is very limiting.

While that may work, it's far harder to think of than "lets make another {{templating|language}}" inside this YAML that we already have and everyone else uses.

Re: Why are we templating YAML? (2019)

#65

Post by spacebanana7 »

simiones wrote: post #35
spacebanana7 wrote: post #10

I wonder whether doing away with config altogether is a solution. Just build an application that calls AWS APIs directly when you want to deploy or update an environment.

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 useful for defining more static values.

Re: Why are we templating YAML? (2019)

#66

Post by vlfig »

Aeolun wrote: post #30
datadeft wrote: post #20

Indeed why? However the conclusion I have is not to use JSON but to use a type safe configuration language that can express my intent much better making illegal states impossible. One example of such lang is Dhall. https://dhall-lang.org/

If I’m going to use a whole language to generate my config already, why would I use anything but the language my application is written in? Everything can export JSON after all.

Different requirements, different guarantees. Principle of least power. Have a look at https://docs.dhall-lang.org/discussions/Safety-guarantees.ht....

Re: Why are we templating YAML? (2019)

#68

Post by TheFuzzball »

baq wrote: post #48
TheFuzzball wrote: post #26

I just knew this would be about Kubernetes when I saw the title. The Kubernetes API is fairly straightforward, and has a well-defined (JSON) schema, people should be spending a bulk of their time learning k8s understanding how to use the API, but instead they spend it working out how to use a Helm chart. I don't think Jsonnet, Ksonnet, Nu, or CUE ever gained that much traction. I'm convinced most people just use Kust…

probably doesn't meet the 2nd requirement, most definitely doesn't meet the third, but: https://cdk8s.io/docs/latest/

The second requirement is actually probably the most important - if someone that just set up ArgoCD, Flux, or has their own GitOps pipeline, how much of a headache does using a new compile step present?

Lots of things are simple in isolation: want to use Cue? Just get your definitions and install the compiler and call it and boom, there are your k8s defs! Ok, but how do I integrate all of that into my existing toolchain? How do I pass config? Etc, etc.

The best, fastest tool won't win. The tool that has the most frictionless user story will.

Re: Why are we templating YAML? (2019)

#70

Post by planede »

BiteCode_dev wrote: post #45

This is where I usually pitch in with "Have your heard of CUELang, our lord and savior?": https://cuelang.org/ - Not turing complete yet sufficiently expressive to DRY - Define schema and data with the same language, in a separate or same file. With union types. - Generate YAML or JSON. Can validate itself, or a YAML or JSON file. The biggest drawback being the only implementation is currently in go, meaning you may…

How does it compare to dhall?
Post reply on HN