I love json. It’s explicit and easy to read. We should just be using json for everything that needs to be human readable.

Just build an application that calls AWS APIs directly when you want to deploy or update an environment.

Yes, logic should live in code, but very often that logic needs to behave differently depending on some piece of (inherently variable, not static) configuration.

Random examples (written from the perspective of personified code): - How many threads should I use? - On which port should I serve metrics? - Which retry strategy should I use?

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.

Just write normal code, make any data structure, print it as any data format. Call the code, output to temp file, use file, delete file.

Is it clunky? Yes. But it works, and you can't get any simpler.

Keep it simple, silly.

Would things like..

A great LSP with semantic autocomplete, Native cross-file imports, and conditionals based on environment make things feel different/better?

What should modern declarative systems be doing in your opinion?

This ugly mess of low-ish level details will never go away. Developers that are trying to focus on developing apps will never enjoy these things and that's fine.

Something like score.dev which abstracts things even further seems to be the way to go as the interface that is exposed to developers.

Moreover the YAML spec allows for specifying the tags recognized per application.

So on two counts, if “on”, “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants, are all boolean literals, it is not YAML’s fault.

It's always been relatively shocking to me that this is still relevant 4 years after I wrote it. Helm is as Ubiquitous as ever, despite attempts to replace it with Jsonnet, Cue and programming languages.

I've personally moved on from Jsonnet and would recommend Pulumi to anyone experiencing this problem.

I love Helm. Helm is magic. Helm makes my life tolerable.

But I’ve templates way too many yaml files.

If it were up to me XML would be default and we would use XSLT for templates.

I’m pretty sure you can use XSLT on JSON, which is logical identical to YAML. So something could be worked out.

Maybe that should be my next open source project.

1) “blind configuration” Such as a CI pipeline config that you commit but can’t validate before you do.

2) Complex markup for config. Anything that can’t fit into a single screen of flat .toml or .ini style config should be code.

I know, I know — everyone raves about the power of separating your code and your data . . . But it's [not] what you really want, or all the creepy half-languages wouldn't all evolve towards being Turing-complete, would they?

https://sites.google.com/site/steveyegge2/the-emacs-problem

Templating YAML is the same, but... Honestly, Jsonnet is too. If you're going to generate JSON — by god use a normal programming language. You have to teach your team one fewer thing (approximately no one knows Jsonnet); it already integrates with your existing build system; if you wrote a useful util function in your main codebase you can reuse it; if you have a typechecker or a linter you can use it; etc etc.

I understand this is a niche use case.

So if you have issues expressing something complex in YAML (like nested arrays) just write JSON instead.

> You know what's good about YAML? No, me neither.

Personally, I love using a Perl hash for my config files. But maybe I'm just mad.

Pick your poison, I guess.

In that instance the queue name is derived dynamically from the hostname.

This article feels very ironic to me hence the sarcasm.

Give me code as configuration and I'll be interested

[0]: https://www.brightbox.com/blog/2020/02/24/rubynetes-getting-...

[1]: https://www.brightbox.com/blog/2020/02/12/rubynetes-kubernet...

[2]: https://www.brightbox.com/blog/2020/02/17/using-openapi-to-v...

Just use dumb YAML, maybe kustomize if you really need, but if that's not sufficient, consider that a sign that you're not carving the wood the way it's telling you to.

Any form of templating for creating your own application manifest is another moving part that allows for new and fun errors, and the further away your source manifest is from the deployed result, the harder it is to debug.

If you really want to append a certain set of annotations to each and every pod in a cluster, instead of using shared templates (and enforcing their usage), there's other approaches in K8s for these kinds of use cases, that you have a lot more control over.

(A) why not use the yaml syntax that is not whitespace sensitive. In the authors example, that could be: {name: Al, address: something}

(B) do env variables not go a long way to avoiding the need for a template? Instead of generating a complete YAML, put env variable placeholders in and set those values in the target environment. At this rate, the same YAML can generally be deployed anywhere. I've seen that style implementated several times, works pretty well.

I do agree that generating config itself, and not just interpolating values - is potentially really gnarly. I do wonder, instead of interpolating variables at deploy time, why not use env variables and do the interpolation at runtime?

By the way the answer to the question "why are we templating yaml?" is: people are just more familiar with it and don't want to have to translate examples to jsonnet that they copy and paste from the web. Do not underestimate this downside :) Same downside would probably apply to TypeScript-generated configs I bet.

Strict YAML is easier to maintain than json if you have deeper than one or maybe two levels of nesting, multiline strings, or comments.

So, I build my config systems to _generate_ YAML instead of “templating YAML.”

PyYAML extensions and ruamel.yaml exist—Though kind of out of date, and more new projects are using TOML. (From project description: “ruamel.yaml is a YAML parser/emitter that supports roundtrip comment preservation”)

Confession: but yeah, not when I use ansible. Ansible double-dog-dares you to “jinja2 all the things” without much in the way of structured semantics.

And a worst contender is embedding text template like jinja in a YAML config and forcing everyone to use such abomination to change production config via deployment. Yes, I'm talking about Terraform or the like. Why people think this kind of design is acceptable is beyond my comprehension.

The reasons I like yaml is that I can see the tree structure directly, and to my lisp brain it is extremely easy to read. Furthermore, in our age of LLMs, I find LLMs to be able to generate "correct" YAML more easily than JSON, since the tree depth is encoded in every line, and doesn't require matching larger structures. It also uses an actually significant amount less tokens.

I find it extremely easy to have LLMs generate decent DSLs by asking them to use a YAML output format, and found it very robust to generate code out of these (or generate an interpreter for the newly created DSL).

I didn't know about !tags until sunday, which is quite shameful, but I find that the emrichen solution is actually quite elegant, and really kind of feels like a lisp macro expander.

Overall, YAML is just good enough for me to get shit done, I can read and skim it quickly, LLMs do well with it, and it's easy to work with. It has aliases, multiline strings and some other Quality of life features built in.

https://github.com/con2/emrichen

We took Starlark added a few more of our instructions that make our Starlark container native. The complex Starlark definition supports

- Composition - you can import a remote definition and just use it - Decomposable - you can break things apart - Parametrizability - want one of a service and 10 of the other, just pass an argument - Portable - It runs pretty much anywhere

Our runtime takes the Starlark and creates environments in both Docker and Kubernetes; from one definition

Our CTO wrote this - https://docs.kurtosis.com/advanced-concepts/why-kurtosis-sta...

We are source available https://github.com/kurtosis-tech/kurtosis

Here is a popular environment definition - https://github.com/kurtosis-tech/ethereum-package that protocol developers use to setup custom Ethereum test environments

https://helm-playground.com/ - https://github.com/shipmight/helm-playground

My solution for this is a sandboxed lua for programatic configuration:

https://github.com/civboot/civlua/tree/main/lib/luck

I can't stand JSON (for many reasons) so I created a serialization format that combines it and CSV for nested objects

https://github.com/civboot/civlua/tree/main/lib/tso

I wish the industry would standardize on a solution like this. IMO you shouldn't use a "real" language unless you can lock it down to be determinisitic. JSON is supposed to be human readable but fails for lots of real-world data like multi-line strings or lists of records.

CSV is more readable but doesn't supported nested objects.

It's kind of a rube-goldberg machine that I made as a bespoke solution to a weird problem but it's been fairly pleasant to work with so far.

https://willhbr.net/2024/01/18/the-code-config-continuum/

It's come to the point that I don't even think about using most charts and just build them myself. The issue with that is that software like Prometheus, Loki, Grafana or f.e. Postgres operators are so complex that it's almost impossible do "fix" them.

This really is like that dog sitting in a burning house and saying "This is fine" because that's how most go on with their day after hitting their head for a few hours and running dozens of pipelines.

In your main yaml file you have something like this:

  packages:
    left_garage_door: !include
      file: garage-door.yaml
      vars:
        door_name: Left
        door_location: left
        open_switch_gpio: 25
        close_switch_gpio: 26

It's the best version of templating YAML that I have experienced.

1. https://esphome.io/guides/configuration-types#packages-as-te...

First we had arbitrary code that did something. Then we thought, "hey wouldn't it be nice if we could do this declaratively in a standard way using configuration instead?" Then we could reason about it more easily. But then came the realization "this declarative system isn't quite powerful enough, what if we could sprinkle some logic on top of it". "Hey wouldn't it be nice if we could go back to doing it declaratively? I guess we can just add the missing features to our not-turing-complete config language". "Wow now it can almost do everything I want.... but there is just this tiny little thing I want to do in addition, let's do templating!" etc

If your configuration is complicated enough that it needs to be generated, then use a real general-purpose language to generate it. Not crummy pseudo-imperative constructs bolted onto the YAML.

At the very least, systems that take YAML as configuration should also take JSON as configuration. GitOps-style systems should allow you to define, not just system.yaml config, not just system.json config, but also system.js config, that is evaluated in some kind of heavily-restricted sandbox.

Every deployed process receives exactly 3 environment variables, NONCE, TAGS and CONFIG_DB_PARAMS. Every process is bootstrapped in the same way:

  1. Initialize config db client.
  2. config = db.fetchConfig(tags)
  3. Use NONCE to signal config changes if needed.

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.

Most devops folks are former sysadmins with no developer experience.

The tools needed to be able to be picked up quickly without too much pain.

This is why our devops tooling in popular usage is not as robust as developer tools.

Know your audience.

The only thing I can think of is that generating these files requires picking a language platform. I chose Ruby to generate the k8s manifests I need.

If you are picking something that is meant to be language-agnostic, or to have very little ramp-up time, then sure, templating. It just comes at a cost where the templating language itself approaches that of a full blown, Turing-complete language as more features gets added, often with shaky foundations (such as HCL).

..it's no more or less declarative than other configuration languages?

And yes, I get that it looks simpler. I just think that it applies as long as your file can fit in about half a page. As it grows and becomes deeply nested, IMO, that simplicity disappears.

You lose a few degrees of freedom and flexibility in your implementation this way, but at the same time you also don't need to wade through pages and pages of configuration documents.

Everything is cyclical. I'm waiting for the next "omakase" offering that provides a sane low-configuration platform for building "cloud native" apps. Right now it looks like we're in an analogue of the XML hell that prompted the design philosophy of Rails and "convention over configuration."

[0] https://dhh.dk/2012/rails-is-omakase.html

[1] https://wiki.c2.com/?ConventionOverConfiguration

I have arrived that I think using typescript to generate JSON as being the ultimate solution.

Easy JSON support, optional typing, you already know it, and adding reusable functions and libraries is understandable. Just prevent external node modules, and have a tool that takes a typescript file with a default export of some JSON and renders the JSON to a string on stdout.

YAML and its ecosystem is full of footguns and ergonomics problems, especially when the length of the document extends beyond the height of a user's editor or viewport. Loss of context with indentation, non-compliant or unsafe parsers, and strange boolean handling to name a few.

It becomes even worse when people decide that static YAML data files should have variable substitution or control flow via templating. "Stringly-typed programming" if you will. If we all started writing JSON text templates I think a lot of people would rightly argue we should write small stdlib-only programs in Python, Typescript, or Ruby to emit this JSON instead of using templated text files. Then it becomes apparent that the YAML template isn't a static data file at all, but part of a program which emits YAML as output. We're already exposing people to basic programming if we're using YAML templates. People brew a special kind of YAML-templated devops hell using tools like Kustomize and Helm, each of which are "just YAML" but are full of idiosyncracies and tool-specific behaviour which make the use of YAML almost coincidental rather than a necessity.

Yes, sometimes people would prefer to look at YAML instead of JSON, in which case I suggest you use a YAML serialization library, or pipe output into a tool like `yq` so you can view the pretty output. In a pinch you could even output JSON and then feed it through a YAML formatter.

The Kubernetes community seems to have this penetrating "oh, it's just YAML" philosophy which means we get mediocre DSLs in "just YAML" which actually encode a lot of nuanced and unintuitive behaviour which varies from tool to tool.

Look at kyverno, for example: it uses _parentheses_ in YAML key names to change the semantics of security policies! https://kyverno.io/docs/writing-policies/validate/ . This is different to (what I think are the much better ideas of) something like kubewarden, gatekeeper, or jspolicy, which allow engineers to write their policies in anything that compiles to WASM, OPA, and Typescript/Javascript respectively.

We engineers, as a discipline, have decades of know-how building and using general purpose programming languages with type checkers, linters, packaging systems, and other tools, but we throw them all away as soon as YAML comes along. It's time to put the stringified YAML templates away and engage in the ecosystem of mature tools we already know to perform one simple task they are already good at: dumping JSON on stdout.

Let's move the control flow back into the tool and out of the YAML.

i like yaml now.

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”, “y”, “n”, “off”, and all capitalized and uppercase variants)? And people are actually using this in production software?

Then when you add templating it’s no longer readable and concise anyways. So, why? In JSON, you can add templating super easily by turning it into regular JavaScript: use global variables, functions and the like. I don’t understand how anyone could prefer YAML with an ugly templating DSL over that.

And if you really care about conciseness, there’s TOML. Are there any advantages of YAML over TOML?

xkcd 927.

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"
    }

So what other "reasons" were there for YAML?

Oh, the human readbility thing. Yeah. Because syntactically relevant whitespace is such a joy in a data serialization format. It's bad enough when a programming language does that (and I am saying this as someone who likes python), but a serialization format? Who thought that would make things easier?

And then of course there are other things filled with joy and happiness...like the multiple ways to write "true" and "false", because that's absolutely necessary for some reason.

"Oh but what about strict-yaml?!" I hear the apologies coming...great, so now I have the ambiguitiy of what parser is used on top of the difficulties introduced by the language itself. Amazing stuff. If that's the solution, then I'd rather not have the problem (aka. the language).

But despite all[1] these[2] problems[3] and more, YAML somehow became the goto language for configuring pretty much everything in DevOps, first in containerization, then in cloud, and everything in between. And as a result, we now have to make sure our config template parsers get whitespace right. Great.

So bottom line: The problem here is maybe 1/3 the complexity of config files and 2/3rd the fact that YAML should have never been used as a configuration format in the first place. It's benefits are too small, and it's quirks make too many problems for that role, outside of really trivial stuff like a throwaway Dockerfile.

Want config? Use JSON. And if you need something more "human friendly", use TOML.

[1]: https://github.com/cblp/yaml-sucks

[2]: https://changelog.com/posts/xml-better-than-yaml

[3]: https://noyaml.com/

The only thing that saves me is IntelliJ's inject-language-in-string feature.

JSON5 has achieved a reasonably high level of adoption (though I think it's plateaued & I don't see it ever becoming the standard way people do JSON). Would be great to at least see StrictYAML hit a similar level of adoption though - the network effect is so hard to overcome.

[1] https://twitter.com/funcOfJoe/status/1319667607214067712

I don’t need a config language with no fewer that 6 subtly different ways of decoding a string to remember, and certainly not one with a spec longer than C’s. Compare to JSON’s, which (famously) fits on a postcard.

https://yaml.org/spec/1.2.2/

https://yaml-multiline.info/

https://www.json.org/json-en.html

No character needs escaping.

That was certainly the selling point. I never saw any advancements in it - the features were aesthetic syntactic sugar.

> 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 everything else.

Also, if you're saving complex object state you don't have a configuration format but a serialization format and definitely ini isn't good for that.

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.

2. The native types in TOML are useful.

XML is by far the most bulletproof human-readable serialisation-deserialisation language there is.

Having said that, I do like that you can flip between YAML and JSON. If we could do that with XML (attributes vs sub-elements a problem here) it would be much more useful I think.

A .nix file is either a config file itself or a function that returns a config file or a function. By passing in enough parameters, you get the configuration. I've not seen as clean a way of doing this anywhere else. Guix uses Guile which is a full programming language and can probably have side effects. They use something called G-Expressions which is not quite clear to me.

Fixed the comment too.

I know TOML has an official spec.

That's all what I'll say.

Notably error reporting is atrocious, but an interactive debugger would be amazing too. Ie to set a breakpoint and hop into an eval at your breakpoint. Would help immensely.

Still i just can't get behind a dynamic typing for anything remotely complex.. which i would describe Nix as. I have been counting down the days for Nickel.. it's been a long wait.

I haven't ignored it, as shown by us discussing it here.

And no, YAML isn't a better way. It does commenting better, true, and at the same time, it does so many things wrong, that are absolutely no problem in JSON, that it becomes a treatment worse than the disease.

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

Fixing _this_ is a good point, though.

I certainly did and I also clarified it a second time. I'm not doing it a 3rd time, you can re-read this chain.

> Configuration and Serialization are the same thing, at the format layer.

CSAM and the text of the bible are the same thing at the storage layer.

My cats and I are the same thing at the atom layer.

And you say this inane thing unironically. Let me quote an earlier comment I made

> 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

stop being an architecture astronaut.

But this just takes the cake.

> they [people] just want a format that gets the job done, and doesn't get in your way.

TFA is very clearly stating that if you're having to template it, it's not getting the job done.

One may write a single value containing a CSV, another may use a convention of namespaced keys, whatever. One may base64, one may urlencode, whatever.

The differences don't change the fact that they will all have the same things in common.

Even without a formal spec, we all know what we are free to change and not free to change, and free to assume and not free to assume. The unwritten spec specifies very little, so what? That means maybe it isn't a good choice for some particular task that wants more structure, but that was not what you said and not what I'm ridiculing.

Or was that all you meant in the first place? That without some more to it to define standardized ways to do things, it's not good for these kinds of jobs? I confess I am focusing on the literal text of the comment as though you were trying to say that the term is not meaningful because it is not defined in a recognized and ratified paper.

Because these are not related to how you write the file, but how your software operates in your mind.

> I think I speak for basically the entire history of programming when I say that ugly solutions exist and are widely used throughout our profession.

I can raise it to the level of the entire history of humanity when I say that people yearn for cleanliness and beauty

> I never argued that this hack solves ugliness.

Sure, because "you choose to ignore [the problem of ugliness] as such". People who share "my opinion" don't ignore that and use cleaner formats, so YAML is a solution that addresses the problem, your suggestion doesn't

jquery vs mootools/scriptaculous/etc.

jquery won for a reason, it's just flat out a better experience in terms of code specifically because it uses a functional approach in its api rather than an OOP approach.

Especially when you're not dealing with the DOM, sometimes objects work quite well.

The original awkwardness does not show that javascript "was never designed to be used like a classic OOP language".

Nor is it why jquery worked well.

And adding these slight changes is not trying to "hammer" javascript into being "more typical OOP".

Starlark is a good option though.

People will talk about Jsonnet not being Turing complete, but IMO that is completely irrelvant. Turing completeness has zero practical significance for configs.

We're living in a dream state now where the creators of IDEs like Visual Studio (Code) or IntelliJ actively implement common languages and frameworks. It used to be 'find a half-baked community plugin so JSON works.'

If someone made a standard schema and people used it, I can assure you the magic you are expecting from your tooling would suddenly pop in just like how JSON support appeared one day. But they can't do nothin' if there is no community support for it.

XSD and XSLT are complicated because XML is complicated.

do not try and downplay something just because you want it to be true.

I thought I remembered more comments on that thread, but I guess nothing more than what's there needs to be said.

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

(1) I want to write something where I can visualize exactly what will be sent to Kubernetes, and visually compare it to the wealth of YAML-based documentation and tutorials out there

(2) I have a set of resources/runners/cronjobs that each require similar, but not identical, setups and environments, so I need looping control flow and/or best-in-class template inclusion utilities

--

People who have been working in k8s for years can dispense with (1), and thus can use various abstractions for generating YAML/JSON that don't require the user to think about {toYaml | indent 8}.

But for a team that's still skilling up on k8s, Helm is a very reasonable choice of technology in that it lets you preserve (1) even if (2) is very far from a best-in-class level.

I think I was getting hung up on the mutations and side-effects of it all. Thanks for putting words to that. I'll have to give it another try sometime. Have you used Terraform's CDK by chance? I assume it's heavily inspired from AWS's CDK, but my company has since moved to GCP/Terraform.

GitHub actions isn't going to run your Python code on its orchestration infra. Nor is DigitalOcean or Fly.io or CircleCI. They all convened around "YAML" because it's a very limited set of instructions.

I'm quite sure you cannot write a bitcoin miner (or something that opens a backdoor) in Liquid inside YAML in the DSL that Github Actions has. I am 100% sure you can write a bitcoin miner in Python, Javascript, Lua, or any programming language that Github would use to replace their YAML config.

You have complex enough logic to warrant a language, you should use a real language. You'll have more support, less obscure issues, a solid standard library and whatever else you want, because it's a REAL language.

If the argument is "someone in my team uses recursion to write the YAML files, so I'll disallow it", then the issue is not with the language, it's with the team.

What I have found on my career is that many Ops people sell themselves short and hesitate to dive into learning and fully using an actual language. I've yet to understand why, but I've seen it multiple times.

They then end up using pseudo-languages in configuration files to avoid this small step towards using an actual language, and then complain about how awful those pseudo-languages are.

There is such a combination project: cppawk.

https://www.kylheku.com/cgit/cppawk/about/

As an aside, on another post yesterday, I had a pleasant surprise about "templating" in life itself.

> The familiar distinction between software and hardware loses its meaning in living cells. We propose new ways to study the phylogeny of metabolisms, new astronomical ways to search for life on exoplanets, new experiments to seek the emergence of the most rudimentary life, and the hint of a coherent testable pathway to prokaryotes with template replication and coding.

https://arxiv.org/abs/2401.09514

Maybe DNA is the original templating language. (Hopefully with more sophistication than fancy string interpolation.)

PHP is a scripting language that is also a template processor, but I wouldn't call it a template language. So we disagree on several points, but no big deal. A big disadvantage of PHP, in relation to your original point about "fancy string interpolation", is that it does not natively understand the target output HTML syntactically and structurally.

What I was trying to do is get you to explain what you mean by this:

> If our code ran in real-time to show us a representation of the final configuration, and we could trace how each final configuration value was generated, then it wouldn't be a problem. [...] But no systems are designed with this capability, even though it is quite trivial to do. Configuration is always an after-thought.

Even Lisp software that uses Lisp for configuration does not necessarily allow programming in that configuration notation.

Since this article is about helm, I'll point out that Go templates are very lispy. I often have things in them that look like {{ and (foo bar) (bar baz) }} and it only gets crazier as you add more parentheses ;)

But in doing so, we've thrown out the other important part of lisp, which is that you can use the same syntax for data that you do for control flow. And so we're stuck in this world where a "modern-looking" program is seen as a thing that must be evaluated to make sense, not a data structure in and of itself.

https://www.reddit.com/r/lisp/comments/1pyg07/why_not_use_in... is a fascinating 10 year old discussion. And of course, there's Smalltalk, which guided others to a treasure it could not possess. But most younger programmers have never even had these conversations.

We're talking countless centuries and great many minds pushed to brink of madness, just to keep the configs looking like Python or JavaScript.

We used to have to shove servers in to racks ! Kids these days :D

Jsonnet is the way to go with generated helm manifests transformed later. Kustomize with its post-renderer hooks is another can of even hotter garbage.

To be extra direct there: I didn't say the effort was small, I said that change was small. You can have a big effort for a small change. So you definitely misread me there.

But when you talked about "hammering" it into a more OOP language, I thought you were talking about big changes or many changes.

> what you're calling "awkwardness with classes" is incorrect. they were _functions_ that you could attach state to, some of that state could, itself, be callable functions. That's a large part of _why_ javascript has prototype inheritance.

Does it matter if the "class" itself is a function or an object or something else entirely? It makes thingies that have the prototype applied and you can do .foo on.

But classes you make with the keyword are still functions, aren't they? So what's the big betrayal?

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 type systems.

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

"source" config --> convert to JSON config "on the fly" --> app that expects JSON

edit: I worked on a C++ team that used `std::system` to invoke the system python interpreter when loading a config file. My teammates weren't morons, either, it's just the simplest thing that worked and they knew that the config script and the surrounding file system were secure.

Spaces aren't a problem.

What is a problem is not picking one or the other. There's arguments for both sides but it is critical to just take a side. I'm sorry your side lost but it makes everything better to just go along with the consensus.

You can’t be serious

The majority of editors can be configured to use tab to insert the appropriate number of spaces. Many will automatically detect the correct configuration.

Python is actually flexible in its acceptance of both spaces and tabs for indentation.

Maybe you were thinking of Nim or Zig? Nim apparently supports an unsightly "magic" line for this (`#? replace(sub = "\t", by = " ")`), and Zig now appears to tolerate tabs as long as you don't use `zig fmt`. I haven't used either yet because of the prejudice against tabs, but Zig is starting to look more palatable.

Now excuse me while I duck under this table.

Not if your editor can be configured to interpret a Tab keypress as the appropriate number of spaces. AFAIK all common text editors, at least in the Unix world, do this.

This isn't a tabs or spaces issue. This is a "your editor is bad or configured wrong" issue.

On the other hand, most operators I've seen are just k8s manifest templates implemented in Go.

I often end up preferring using Jsonnet to deal with that instead of doing the same stuff in Go.

Jsonnet is much more close to the underlying datamodel (the k8s manifest Json/Yaml document) and comes with some useful functionality out of the box, such "overlays".

It has downsides too! It's untyped, debugging tools are lacking, people are unfamiliar with it and don't care to learn it. So I totally get why one would entertain the possibility of writing your "templates" using a better language.

However, an operator is often too much freedom. It's not just using Go or Rust or Typescript to "generate" some Json manifests, but it also contains the code to interact with the API server, setup watches, and reactions etc.

I often wish there was a better way to separate those two concerns

I'm a fan of metacontroller [1], which is a tool that allows you to write operators without actually writing a lot of imperative code that interacts with the k8s API, but instead just provide a general JSON->JSON transformer, which you could write in any langue (Go, Python, Rust, Javascript, .... and also Jsonnet if you want).

I recently implemented something similar but much tailored to just "installing" stuff, called Kubit. An OCI artifact contains some abitrary tarball (generally containing some template sources) and a reference to a docker image containing an "engine" and runs the engine with your provided tarball + some parameters passed in a CRD. The OCI artifact could contain a helm chart and the template engine could contain the helm binary, or the template engine could be kubecfg and the OCI artifact could contain a bunch of jsonnet files. Or you could write your own stuff in python or typescript. The kubit operator then just runs your code, gathers the output and applies with with kubectl apply-set.

1. https://metacontroller.github.io/metacontroller/intro.html

2. https://github.com/kubecfg/kubit

You give the apiserver a document describing what resources you need. The Operator actually does the work of provisioning those resources in the "real world" and (should) update the status field on the API object to indicate if those resources are ready.

And the double nature of the spaces makes it hard to see when you have an odd number of spaces when you reach deep indenting levels, which counts as the lesser number of double spaces in Python.

IMO it would be ideal if tabs would be displayed as a block, and you could resize the width of that block on the fly <3

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 something, and figure out the rest of the process as you go.

Edit: blocks became blogs without my knowledge. Maybe I should write a blog post about it. Don't know.

Tab indentation has no bugs or corner cases.

  if !exists("g:python_recommended_style") || g:python_recommended_style != 0
    " As suggested by PEP8.
    setlocal expandtab tabstop=4 softtabstop=4 shiftwidth=4
  endif

You can set that g:python_recommended_style to disable it.

Also sw=0 uses the tabstop value, and softtabstop=-1 uses the shiftwidth value.

I agree Vim's behaviour there is a bit annoying and confusing, but it doesn't really have anything to do with tabs vs. spaces. I strongly prefer tabs myself as well by the way.

Even when you DO use tabs Vim will use spaces if sw/ts/sts differ by the way. Try sw=2 and using >>, or sts=2 with noexpandtab.

The nice modern twist is .editorconfig files and the plugins that support them including for vim. You can use those to set such standard language-specific config concerns in a general way for an entire "workspace" for every editor that supports or has a plugin that supports .editorconfig.

Backspace doesn't unindent in vim by default, it removes spaces one at a time. That's a difference between the ts=4 (tab stop) and sts=4 (soft tab stop) is sts also applies to backspace. But the default is that it doesn't because the out of the box default believes that backspace operates on physical characters (spaces) not soft/fake ones (tabs expanded to spaces) by default.

I don't know if that is the right default, and it is definitely a baroque exercise to get all the settings right for some languages, but there is a consistency to the defaults even if those defaults don't meet some modern expectations from newer code editors.

(Also, I just realized above I confused tw [text width] and ts [tab stop]; my vim skills are rusting a little.)