4 ms·

I don't hate YAML. Who hates YAML?

by emodendroket 3y ago

baq 3y ago
I didn’t, then I’ve started writing GitHub actions and now I do.
- pydry 3y ago
  Github actions is fine provided you keep the YAML as short as possible and try to call out to a normal script to do everything - i.e. use it as config. The problem comes when you try to use it as a programming language in and of itself (which MS encourages because it's a route to vendor lock in). It's a shitty, shitty programming language with shitty debugging tools.
  - baq 3y ago
    To your first point: yes. To your second point: yes, yes, and very much yes. Creating complex release workflows within GHA is hell given the debugging situation and that's what we're using because 'it's there, use it, everyone's using it'. Send help
orphea 3y ago
I do. YAML can return to the rotting hole it's from.
funcDropShadow 3y ago
Me and anyone who read https://noyaml.com/ https://noyaml.com/ .
- emodendroket 3y ago
  So a handful of well-known pitfalls and complaints about how it’s easy to represent the same information differently. Yeah, switching to XML definitely solves that problem.
  - sph 3y ago
    The fact that you know them doesn't make them any better, it just proves you've got Stockholm Syndrome
    - emodendroket 3y ago
      I get your point but there is exactly no technology you can use without some known pitfalls, so you pick the one whose pitfalls are the least catastrophic or bothersome to you.
sethammons 3y ago
I have literally left a 300k+/yr job, twice, due to having to write and maintain too much yaml. Templating and significant whitespace is the worst. 10 commits in a row of "error on line 1" until helm finally parses what you want. I am a software developer with extensive distributed systems experience. I like thinking about systems, not guess-and-check on config templates that become a bespoke DSL with no proper way to debug. Our config structure requires similar but individualized configs for on-prem and the cloud. These can deviate for the region, the data center, the logical cluster, and at the individual node level for A/B or canary reasons. And of course local dev. You need to have a way to know where the deviations are, like different regional hostnames for services you connect with, different node sizes or replica counts, and different labels, any of which may or may not be correct and will cause an incident if wrong. Search you yaml PRs, and I bet you will find a commit along the lines of "because yaml."

I don't hate YAML. Who hates YAML?

baq 3y ago

I didn’t, then I’ve started writing GitHub actions and now I do.

pydry 3y ago
Github actions is fine provided you keep the YAML as short as possible and try to call out to a normal script to do everything - i.e. use it as config. The problem comes when you try to use it as a programming language in and of itself (which MS encourages because it's a route to vendor lock in). It's a shitty, shitty programming language with shitty debugging tools.
- baq 3y ago
  To your first point: yes. To your second point: yes, yes, and very much yes. Creating complex release workflows within GHA is hell given the debugging situation and that's what we're using because 'it's there, use it, everyone's using it'. Send help

orphea 3y ago

I do. YAML can return to the rotting hole it's from.

funcDropShadow 3y ago

Me and anyone who read https://noyaml.com/ https://noyaml.com/ .

emodendroket 3y ago
So a handful of well-known pitfalls and complaints about how it’s easy to represent the same information differently. Yeah, switching to XML definitely solves that problem.
- sph 3y ago
  The fact that you know them doesn't make them any better, it just proves you've got Stockholm Syndrome
  - emodendroket 3y ago
    I get your point but there is exactly no technology you can use without some known pitfalls, so you pick the one whose pitfalls are the least catastrophic or bothersome to you.

sethammons 3y ago

I have literally left a 300k+/yr job, twice, due to having to write and maintain too much yaml. Templating and significant whitespace is the worst. 10 commits in a row of "error on line 1" until helm finally parses what you want. I am a software developer with extensive distributed systems experience. I like thinking about systems, not guess-and-check on config templates that become a bespoke DSL with no proper way to debug. Our config structure requires similar but individualized configs for on-prem and the cloud. These can deviate for the region, the data center, the logical cluster, and at the individual node level for A/B or canary reasons. And of course local dev. You need to have a way to know where the deviations are, like different regional hostnames for services you connect with, different node sizes or replica counts, and different labels, any of which may or may not be correct and will cause an incident if wrong. Search you yaml PRs, and I bet you will find a commit along the lines of "because yaml."