But they don't both suck. Newer tools reflect the needs of newer problems. Like, I can point to exactly what I get from my Chef/Cfer stack--I can wrangle hundreds of concurrent machines that need to update to a policy while also getting, in a standardized and predictable format, a full itemization of all changes applied to all systems. I can leverage the community, too, to help me bootstrap new features and functionality because we're speaking a shared language.

They might be new tools to you, and being skeptical of new stuff is fine (even healthy), but there's a point at which skepticism turns into Ludditism and it's well before the point where one starts to bloviate about "hipster software".

It's funny you'd quote Chef (or puppet), because they've been replaced by Ansible/Salt.

I spend a lot of time evaluating new tools, possibly more so than anyone else in this tread. There are very few novelties which solve a problem notably better than what existed before AND are reliable enough for serious usage AND don't come with so many drawbacks that it nullify their interests.

Chef hasn't been replaced by Ansible or Salt. Each tool has a different value prop that makes sense in different contexts. I might use Ansible in some environments where I wouldn't use Chef--there aren't a ton of these environments, IME, but I've chosen to use Ansible in the past despite it not being my favorite for reasons like this. I would use Chef in other contexts where Ansible's ecosystem or tooling is lacking--I find that chef-zero and berkshelf are a better way to self-bootstrap on AWS when using CloudFormation, for example--or where I desire the greater flexibility and expressiveness of a Ruby-based DSL.

The black-and-white thing you're painting is, if I'm gonna be frank...a little messed up. I mean this in the best of ways: please enhance your chill. It's not that bad out here.