>> Such questions may be decided by personal preferences, but their impact can easily be demonstrated.
> I really don't think this is true. What was the demonstrated impact of writing Terraform in Go rather than Rust? Would writing Terraform in Rust have resulted in a better product? Would rewriting it now result in a better product? Even among engineers with 15 years experience you're going to get differing answers on this.
Rewriting from Go to another language wouldn’t solve the problem better. Because Go is an implementation choice, not a design choice. There’s nothing in Go that make Terraform better. It could be in C and a lot of people wouldn’t notice.
You somewhat answered it in a way that doesn't really get to why they asked it (you can't make every decision based on "demonstrated impact").
But you did that in a different comment than the one I replied to. The one I replied to was just answering the wrong question entirely. Which is why I replied.
> Rewriting from Go to another language wouldn’t solve the problem better. Because Go is an implementation choice, not a design choice. There’s nothing in Go that make Terraform better. It could be in C and a lot of people wouldn’t notice.
I'm sorry, are you arguing that using feel to decide how to structure a piece of code is a "huge red flag", but the choice of entire programming language is unimportant?
From my first reply, I've been arguing that using feels to decide things is very much dangerous. There are usually a less ambiguous way to frame the reasons behind a decision. Methodologies like the five why's can help.
And choosing a programming language is orthogonal to designing a solution to a problem. Everything get turned to opcodes and binary at some point.
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.