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.

▲

Dylan16807 3 days ago | parent [-]

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.

▲

skydhash 3 days ago | parent [-]

>> 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.

▲

Dylan16807 3 days ago | parent [-]

Context. That wasn't the original question. That's a short restatement of the real question which is up in an earlier post:

>> 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.

▲

skydhash 3 days ago | parent [-]

And I’ve already answered that question. One of the main impact is that if you want a contributor to the codebase, the person have to learn Go. Even if they have good knowledge of the domain and are proficient in Rust. There would be some cost associated to training that person in Go (it may be small).

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.

▲

Dylan16807 3 days ago | parent | next [-]

> And I’ve already answered that question.

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?

	▲	skydhash 3 days ago \| parent [-]
		> 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.

▲

3 days ago | parent | prev [-]

[deleted]