11 ms·

Such questions may be decided by personal preferences, but their impact can easily be demonstrated. Such impacts are what F. Brooks calls accidental complexity

by skydhash 11mo ago

Such questions may be decided by personal preferences, but their impact can easily be demonstrated. Such impacts are what F. Brooks calls accidental complexity and we generally called technical debt. It's just that, unlike other engineering fields, there are not a lot of physical constraints and the decision space have much more dimensions.

mjr00 11mo ago
> 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 11mo ago
  The impact is that now, if you want to modify the project in some way, you will need to learn Go. It's like all the codebases in COBOL. Maybe COBOL at that time was the best language for the product, but now, it's not that easy to find someone with the knowledge to maintain the system. As soon as you make a choice, you accept that further down the line, there will be some X cost to keep going in that direction and some Y cost to revert. As a technical lead, more often you need to ensure that X or/and Y don't grow to be enormous.
  - mjr00 11mo ago
    > The impact is that now, if you want to modify the project in some way, you will need to learn Go. That's tautologically true, yes, but your claim was > Either you know the problem domain and can argue about which solution is better and why. Or you don't and what you're doing are experiment to learn the domain. 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? Remember, this is objective fact, not art, so no personal preferences are allowed.
    - skydhash 11mo ago
      Neither. Because the solution for IaC is not Go or Rust, just like the solution for composing music is not a piano or a violin. A solution may be Terraform, another is Ansible,… To implement that solution, you need a programming language, but by then you’re solving accidental complexity, not the essential one attached to the domain. You may be solving, implementation speed, hiring costs, code safety,… but you’re not solving IaC.
      - Dylan16807 11mo 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.
        skydhash 11mo ago
        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 11mo ago
        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.

mjr00 11mo ago

> 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 11mo ago
The impact is that now, if you want to modify the project in some way, you will need to learn Go. It's like all the codebases in COBOL. Maybe COBOL at that time was the best language for the product, but now, it's not that easy to find someone with the knowledge to maintain the system. As soon as you make a choice, you accept that further down the line, there will be some X cost to keep going in that direction and some Y cost to revert. As a technical lead, more often you need to ensure that X or/and Y don't grow to be enormous.
- mjr00 11mo ago
  > The impact is that now, if you want to modify the project in some way, you will need to learn Go. That's tautologically true, yes, but your claim was > Either you know the problem domain and can argue about which solution is better and why. Or you don't and what you're doing are experiment to learn the domain. 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? Remember, this is objective fact, not art, so no personal preferences are allowed.
  - skydhash 11mo ago
    Neither. Because the solution for IaC is not Go or Rust, just like the solution for composing music is not a piano or a violin. A solution may be Terraform, another is Ansible,… To implement that solution, you need a programming language, but by then you’re solving accidental complexity, not the essential one attached to the domain. You may be solving, implementation speed, hiring costs, code safety,… but you’re not solving IaC.
    - Dylan16807 11mo 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.
      - skydhash 11mo ago
        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 11mo ago
        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.