A lot of people working with YAML have an ops background and aren't familiar with basic data structures.

That’s disingenuous. Most “ops” folks I work with despise templating files but it’s the easiest way to parameterize things, especially when providing ways for “devs” to do “ops”.

Yes, we may not have a cleaner way of deploying k8s Deployment configs to different clusters but the desire to templatize YAML is easy for everyone to understand. The decision to abstract or templatize is one rooted in time and cost, not ability to understand data structures.

personally I’d prefer a templatized yaml file over an over-engineered, snowflake DSL created by a “real programmer” and not an ops person.

Ok, those aren't the only two choices though.

It probably starts with an existing YAML config file that you only need to pass one or two variables to. Then things get out of hand.

What is "an encoder"? Like a function that takes the same variables as the template would but does some work itself generating things?

An encoder is anything that serializes some data. Think `JSON.stringify()`.

YMMV, I believe most folks would call that "serialization," reserving "encoding" for turning a notionally written-down-ish representation into bytes; e.g. string -> utf8 bytes, or float -> IEEE-754 bytes.

Right, for some reason in Go (which Helm is written in), the standard library calls them encoders/decoders with marshal/unmarshal as the operations. Serialize is definitely the more common term generally.

I've seen it used even more generally for any `A -> B` (or `A -> Option<B>`) where B could be faithfully decoded back to A.

In my head, serialization is a special case of encoding when B is some type of string. In this case it's YAML.

I could probably have worded my previous comment more precisely.