← Back to context

Comment by Dylan16807

2 months ago

> Neither.

> A solution may be Terraform

They're asking about what language you use to write Terraform.

It's not accidental complexity, it's what the question is about.

It’s very much accidental complexity. As the sibling comment to my previous comment said, the choice of a language does not depend on Terraform design, but on contextual information like the team skill, business requirements like time delivery and implementation correctness. None of which really impacts the design of Terraform as a solution. Just like SMTP or Posix tools does not care about the language.

  • If you're talking about the topic, it's not accidental, it's mandatory, because you have to write Terraform in something.

    The topic is not how you use Terraform or at a high level design its features, it's how you implement Terraform with code.

    > the choice of a language does not depend on Terraform design, but on contextual information like the team skill, business requirements like time delivery and implementation correctness

    That doesn't make it accidental to the topic. It may be accidental to a different topic (the design of Terraform?) that nobody was discussing, but it's not accidental to this topic (language choice).

    That list of factors is how you get closer to making the decision.

    • >> So, assuming the domain of infrastructure-at-code is mostly known now which is a fair statement -- which is a better choice, Go or Rust, and why?

      This was the question. And my answer was that Go or Rust have no relevancy in the IaC domain. Ansible is relevant, but Python is not. Chef is relevant, Ruby is not. And I’m pretty sure there are in-house stuff that are just Perl scripts.

      The goal is solving some problem in IaC, by the time, you are considering language choice, you’ve already left the domain and are looking at implementation problems where each choice is balancing tradeoffs.

      5 replies →