1. 21

  2. 7

    The irony is that he’s now trying to build better tools that use embedded DSLs instead of YAML files but the market is so saturated with YAML that I don’t think the new tools he’s working on have a chance of gaining traction and that seems to be the major part of angst in that thread.

    One of the analogies I like about the software ecosystem is yeast drowning in the byproducts of their own metabolic processes after converting sugar into alcohol. Computation is a magical substrate but we keep squandering the magic. The irony is that Michael initially sqauandered the magic and in the new and less magical regime his new tools don’t have a home. He contributed to the code-less mess he’s decrying because Ansible is one of the buggiest and slowest pieces of infrastructure management tools I’ve ever used.

    I suspect like all hype cycles people will figure it out eventually because ant used to be a thing and now it is mostly accepted that XML for a build system is a bad idea. Maybe eventually people will figure out that infrastructure as YAML is not sustainable.

    1. 1

      What alternative would you propose to DSLs or YAML?

      1. 4

        There are plenty of alternatives. Pulumi is my current favorite.

        1. 3

          Thanks for bringing Pulumi to my radar, I hadn’t heard of it earlier. It seems quite close to what I’m currently trying to master, Terraform. So I ended up here: https://pulumi.io/reference/vs/terraform.html – where they say

          Terraform, by default, requires that you manage concurrency and state manually, by way of its “state files.” Pulumi, in contrast, uses the free app.pulumi.com service to eliminate these concerns. This makes getting started with Pulumi, and operationalizing it in a team setting, much easier.

          Which to me seemed rather dishonest. Terraform’s way seems much more flexible and doesn’t tie me to Hashicorp if I don’t want that. Pulumi seems like a modern SAAS money vacuum: https://www.pulumi.com/pricing/

          The positive side, of course, is that doing many programmatic-like things in Terraform HCL is quite painful, like all non-turing programming tends to be when you stray from the path the language designers built for you … Pulumi handles that obviously much better.

          1. 3

            I work at Pulumi. To be 100% clear, you can absolutely manage a state file locally in the same way you can with TF.

            The service does have free tier though, and if you can use it, I think you should, as it is vastly more convenient.

            1. 3

              You’re welcome to use a local state file the same way as in Terraform.

            2. 1


        2. 5

          […] think about what “buy local” might mean for tech. Support smaller projects and ISVs. Interact. Most of us seem to feed more on interaction than anything else.

          I like this point. That choosing to use, support, and interact with somebody’s small project gives them, in turn, the energy and joy and motivation to keep contributing; and that this enthusiasm benefits not just the individuals and the small projects, but also benefits other (larger) projects they contribute to, and the community of open source enthousiasts as a whole.

          Leaving appreciative comments is one of the things that keeps a community of makers (any kind, from fanfic to forums to software to docs) lively, nice to be a part of, and helps ensure a steady supply of new works and active makers.

          1. 2

            If you’re deploying only NixOS instances, NixOps makes things very nice.

            It’s certainly one of the smaller projects, and may work in a more limited number of circumstances compared to something like Ansible, but it’s great when you can use it.

            1. 1

              You would think if someone wrote one of the most contributed to things on GitHub… … people would want to try his new things and share ideas, but my forum has only about 60 members, only 10 who have logged in the last week.

              It does sound like whining to me.

              I agree with his observation but I don’t see anything constructive in the article.

              1. 1

                So the right response is to leave a negative and equally nonconstructive comment? Thanks for the insight.

                1. 1

                  And the cycle continues. :)

              2. 1

                Can someone elaborate on what he means by agile burning people out?

                1. 6

                  I interpreted it as in the context of free software contribution. It simply isn’t sensible on a modern software project to suggest spending considerable time working on random tooling, because project management style and language has evolved to the point where the value of doing so can’t even be captured. “I’d like to add [X] to software [Y]” .. “Great, but what user story does this relate to? We’re focusing on the billing feature this week - there are 17 tickets still open for that due end of sprint Friday”, etc.