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

521–530 of 667 posts

Re: Why are we templating YAML? (2019)

#521

Post by throwaway894345 »

jrockway wrote: post #499
tomjakubowski wrote: post #472

Earlier quoted context omitted.

"because you are trying to describe a program in a data structure" (cries in lisp)

Yeah, I think describing a program in a data structure is fine. I honestly prefer it to any syntax that a "real" programming language has brought me. It's so consistent and you can really focus on what you care about. What is unhappy about Github Actions and similar is that your programming language has like 2 keywords; "download a container" and "run a shell script". I would have preferred starting with "func", "han…

The problem I have with GitHub Actions is that I usually want to metaprogram them. I have a monorepo and I want a particular action to run for each "project" subdirectory. I've written a program that generates GitHub Actions YAML files, but all of the ways to make sure the generator was run before each commit are fairly unsatisfying.

The problem I have with infra-as-code tools is that what I really want is a pretty simple representation for "the state of the world" that some reconciliation can use, and then I want to generate that stuff in a typesafe, expression-based language like TypeScript or Python (Dhall exists, but its Haskell-like syntax and conventions are too steep a learning curve to get mainstream adoption). Instead we get CloudFormation and Terraform which shoehorn programming language constructs into a configuration language (which isn't strictly an objection to code-as-data generally) or things like Helm which uses text templates to generate a "state of the world" description or these CDKs which all seem to depend on a full JavaScript engine for reasons that don't make sense to me (why do I need JavaScript to generate configuration?).

Re: Why are we templating YAML? (2019)

#522

Post by smaudet »

PH95VuimJjqBqy wrote: post #500
smaudet wrote: post #420

Earlier quoted context omitted.

> I'm a fan of either using a full-blown programming language or ini files How do you persist complex multi-object state? Think nested lists of objects with references to one another. If your answer is still "ini files", I'm sure it can be done, but only with a lot of custom-rolled code...xml/json(even yaml) for all their issues provided a code-free way of persisting this all - either through use of marshalling (xml)…

you cut off the part of my statement that answers your question > if you can get away with not needing a full-blown turing complete language then convention based ini files are vastly easier on the human than yaml or json. My claim isn't that ini files solve for every use case, it's that if your needs are simple enough ini files are superior to json/yaml, but that full-blown turing complete languages are superior to…

> 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 "dynamic" vs "static" data, but that's an operational perspective. From the perspective of the application maintainer, there is no difference.

Re: Why are we templating YAML? (2019)

#523

Post by lamontcg »

anon291 wrote: post #514
lamontcg wrote: post #488

Earlier quoted context omitted.

> 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. The problem is language nerds write languages for other language nerds. They all want it to be whatever the current sexiness is in language design and want it to be self-hosting and be able to write fast multithreaded webservers in it and then it becomes conceptually com…

I mean... Nix satisfies every single one of what you mentioned and people say its too complicated. It's literally just the JSON data structure with lambdas, which really is basic knowledge for any computer scientist, and yet people complain about it. It's fairly straightforward to 'embed' and as a bonus it generates json anyway (you can use the Nix command line to generate JSON). Me personally, I use it as my templat…

Tried to use Nix as a homebrew replacement and failed to get it installed correctly with it blowing up with crazy error messages that I couldn't google. I didn't even get to the point of assessing the language. It really seems like the right kind of idea, but it doesn't seem particularly stable or easy enough to get to that initial payoff. If there's a nice language under there it is crippled by the fact that the average user is going to have a hard time getting to it.

Re: Why are we templating YAML? (2019)

#524

Post by hitchstory »

AndyKluger wrote: post #501
khimaros wrote: post #417

Earlier quoted context omitted.

StrictYAML solves most if not all of these problems https://hitchdev.com/strictyaml/features-removed/

StrictYAML is great (and the author is in these comments!), but ultimately it's one specific library, not a format spec, so to depend on it for a project you need every person/tool doing the writing/parsing to commit to use that library (and the programming language it was written for). Again, it's a great project, but I wanted something similar that is a language-agnostic format specification, so moved on to using N…

It is on my to do list to make a spec and a language independent test suite but both of these things take time.

Re: Why are we templating YAML? (2019)

#525

Post by lamontcg »

hnlmorg wrote: post #520
lamontcg wrote: post #488

Earlier quoted context omitted.

> 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. The problem is language nerds write languages for other language nerds. They all want it to be whatever the current sexiness is in language design and want it to be self-hosting and be able to write fast multithreaded webservers in it and then it becomes conceptually com…

There’s plenty to choose from that support embedding: Python, Perl, Lua. Heck, even EMCAScript (JavaScript, VBA, etc). As another commenter rightfully stated, this used to be the norm. I wouldn’t say LOGO is the right example though. It’s basically a LISP and is tailored for geometry (of course you can do a heck of a lot more with it but its strength is in geometry).

You're really missing the point. Logo was super simple and we learned it in elementary school as children, that's all that I'm talking about. And those other languages have accreted way too many features to be simple enough.

Re: Why are we templating YAML? (2019)

#526

Post by Syntonicles »

valty wrote: post #164

It's funny how little developers think about how to do configuration right. It's just a bunch of keys and values, stored in some file, or generated by some code. But its actually the whole ball game. It's what programming is. Everything is configuration. Every function parameter is a kind of configuration. And all the configuration in external files inevitably ends up as a function parameter in some way. The problem…

This is something I'm trying really hard to do with a client. They have a bunch of 1500+ line "config" files for products, which are then used to make technical drawings and production files. The configs attempt to use naming scheme to group related variables together.

I want to migrate to an actual nested data-structure using (maybe) JSON - and these engineers absolutely will not write code, so config-as-code is a no-go, in addition to the disadvantage you mentioned.

My next thought was that there should be a better way to show the configuration, and allow that configuration to be modified. I was thinking maybe some sort of visual UI which where the user can navigate a representation of the final product, select a part and modify a parameter that way.

Is that along the lines of your suggestion? If not will you please expand a little? Configuration is the absolute core of this application.

Re: Why are we templating YAML? (2019)

#527

Post by turboponyy »

unshavedyak wrote: post #432
zamalek wrote: post #378

Earlier quoted context omitted.

The problem goes deeper. I can't remember who coined the term, but all "implerative" (imperative declarative) languages share the same issue. I don't care if it's JSON, XML, TOML, or YAML, we shouldn't be interpreting markup/data languages. GitHub actions are a good example of everything wrong with implerative languages. Use a real programming language, you can always read in JSON/YAML/whatever as configuration. Goog…

Oh man, i have a similar issue with NixLang. Though i know it's not "implarative". Many days i just want to write Nix in my preferred language. I wish Nix had made a simple JSON based IO for configuration, because then i could see what the output of something is - and generate the input state from some other language. Really frustrating. Nix works.. but i just don't see the value, personally. And this is after living…

Completely opposite experience for me. I think Nixlang is exceptionally well designed and makes sense for the usecases it wants to cover, and it is exactly what I would expect from a DSL tackling the problems it tackles.

Re: Why are we templating YAML? (2019)

#528

Post by Draiken »

mark_and_sweep wrote: post #447
Draiken wrote: post #226

Earlier quoted context omitted.

JS is actually not that great for this IMO. You probably need an NPM package to even deal with YAML because JS has a shitty standard library. Sticking to a scripting language with a strong standard library is way better. Any unix system can get Ruby/Python and read/write YAML/JSON immediately without caring too much about versions. Of course in today's upside down world most developers seem to only know JS, so it wou…

Parent is talking specifically about writing JSON, not YAML.

Yeah, but the article is about YAML and my original comment was about configuration in multiple formats.

So, to clarify, for JSON JS is definitely not the worse option. For me though, even for JSON, you have much better options.

Re: Why are we templating YAML? (2019)

#529

Post by theshrike79 »

dragonwriter wrote: post #340
theshrike79 wrote: post #234

Earlier 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.

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

> It is specified in an Internet Draft at the IETF, currently in 2020-12 draft, which was released on January 28, 2021

It took them a few decades to catch up to XML. Support for Schema is still a bit dodgy in most big libraries.

Re: Why are we templating YAML? (2019)

#530

Post by thinkmassive »

jrockway wrote: post #491

Yeah, I'm very sad that helm won. We do OSS k8s stuff at work, and 100% of users have asked for us to make a helm chart. So we had to. It is miserable to work on; your editor can't help you because the files are named like "foo.yaml" but they aren't YAML. You have to make sure you pipe all your data through "indent 4" so that things are lined up correctly in the YAML. What depresses me the most is that you have to re…

> I have definitely done some terrible things like "sed -e s/$FOO/foo/g" to implement templating

Next time you reach for this, check out envsubst for a slightly improved solution that’s somewhat standard (at least common).

On the topic of templating or modifying helm charts using jsonnet, you might find Tanka helpful:

https://tanka.dev/helm

Post reply on HN