Give it a couple of months: Why the f*ck are we templating JSON
This article feels very ironic to me hence the sarcasm.
Give me code as configuration and I'll be interested
Why are we templating YAML? (2019)
281–290 of 667 posts
Re: Why are we templating YAML? (2019)
#282Earlier quoted context omitted.
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.
> Validating incoming XML was a breeze, just give it to the validator class along with the DTD and Schema and boom , done. See the boom ? It's boomer tech. We can't have old, boomer tech in 2024. Jokes aside, I wish people spent the time to understand the technologies before disliking them and blindly implementing a different, inferior one.
XML is more popular today than it's ever been. It's just called JSX now.
Re: Why are we templating YAML? (2019)
#283Earlier quoted context omitted.
I'm a big fan of Python as configuration for my own projects, but: - It requires discipline for devs to keep the conf declarative. Discipline is not automatically enforceable, so it's prone to failure. - No guarantee of reproducibility. - You need a Python VM (or a starlark interpreter if that's what you like). It's a big constrain. - If you are a Saas provider, accepting Python as input is really hard to secure.
a Dhall configuration file will never: - throw an exception - crash or segfault - accept malformed input - produce malformed output - hang or time out in https://docs.dhall-lang.org/discussions/Safety-guarantees.ht... Still a fan of Python for configuration?
Yes, because engineering is about context.
Re: Why are we templating YAML? (2019)
#284My personal philosophy is that string interpolation should not be used to generate machine-readable code, and template languages are just fancy string interpolation. We've all seen the consequences of SQL injection and cross-site scripting. That's the kind of thing that will keep happening as long as we keep putting arbitrary text into interpreters. Yes, this means I don't think we should use template files to make H…
This is the essence of the problem! Yaml and templates are just distractions. It just boils down to the fact that "string" is a very general type and we use it lazily. My personal rule: Every time a value is inserted into a string it must be properly encoded. I wrote a full blog post around this a while back https://kevincox.ca/2022/02/08/escape-everything/ . But the TL;DR is that every string has a format which need…
> My personal rule: Every time a value is inserted into a string it must be properly encoded.
This is how Django templates have done it for over a decade. You have to go out of your way to tell it not to escape the values if for some reason you need that.
Re: Why are we templating YAML? (2019)
#285To 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”,…
HJson https://hjson.github.io seems a nice 'in-between' between YAML and JSON without the indentation-based syntax, so closer to the JSON side but with comments and less quotes.
What I don't really get is why the cloud providers / tooling implementors have never drafted up a "YAML-light" that just throws out the rarely-used headache-inducing syntax elements.
Re: Why are we templating YAML? (2019)
#286Earlier quoted context omitted.
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…
maybe yaml should standardise hygienic macros. and a repl.
The lengths people go to avoid using s-expressions never ceases to amaze me.
We're talking countless centuries and great many minds pushed to brink of madness, just to keep the configs looking like Python or JavaScript.
Re: Why are we templating YAML? (2019)
#287This 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…
we have a pipeline that ingest very concise cuelang files. then it generates json files for each application for a tool that will create xml definitions which then are applied to a xls which the architects own, to spit out a yaml that we use to apply our helm charts. the charts deploy a k8s client which then interact with the main cluster via json using the api. took a while, but we are using the best tool for each j…
You used JSON twice, how casual.
Your API should clearly be using protobuf.
Re: Why are we templating YAML? (2019)
#288Earlier quoted context omitted.
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
My favorite pattern in HCL is the if-loop. Since there is no »only do this resource if P« in Terraform, the solution is »run this loop not at all or once«.
Re: Why are we templating YAML? (2019)
#289It's fashionable to hate YAML. And sometimes rightly so. But what are the alternatives? JSON, XML, INI, TOML, Dahl, Cue, JSONNET, HCL, your programming language of choice. Also let's agree on the target use case - in that YAML is largely used for configuration and operational tasks. If I were to rank-order the features necessary in a good configuration language they would be 1) readability 2) data/schema validation 3) stackability/composability 4) language support 5) editor support 6) industry adoption. So let's do a comparison:
YAML is fairly easy to read, has schema validation with the right library, and is pretty ubiquitous. It can get unwieldy like JSON though.
XML is big, ugly, unreadable. No one likes XML despite it's robust schema validation capabilities.
Your programming language of choice doesn't work because of the target use case unless you truly are a build-run group.
INI it too simplistic for many environments.
HCL is included because I'm a bit of a Terraform fanboy and it has great features like validation, readability and composability. However you're not going to find it in the wild as a general purpose configuration language - outside of Terraform it just hasn't taken hold.
Does anyone really use Dahll? (Serious question.)
JSON is nice because everyone understands JSON. JSON is not nice because all the brackets, braces, quotes, etc get in the way and make sufficiently large configurations hard to read. With the right library you can get schema validation.
JSONNET suffers from the same problems that JSON does, but adds more operations which makes sufficiently large things very hard to read.
TOML is nice and reminds me of INI in it's simplicity.
Cue looks and smells like JSON, has schema validation, but is much more readable.
If I were to rank-order these options it would be 1) Cue 2) TOML 3) YAML 4) JSON 5) your programming language of choice 6) JSONNET 7) INI 8) HCL 9) XML 10) Dahll (maybe?). My point here is that while YAML has a lot to be desired it's still very useful for most implementations and is better than many of the alternatives.
Re: Why are we templating YAML? (2019)
#290I 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…
Pulumi is enticing because it allows you to write in your preferred language and abandon HCL, but it is strictly worse in my opinion. IaC should be declarative in my opinion. That allows for greater predictability, reproducibility and maintainability. In general, I think wanting to use Python or Ruby or whatever language you're going to use with Pulumi is not a good basis for choosing the tool. There are many graveya…
The fact that HCL has poor/nonexistent multi-language parsing support makes building tooling around terraform really annoying. I shouldn't have to install Python or a Go library to read my HCL.