4 ms·

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

by mjr00 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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.
        skydhash 10mo ago
        >> 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.
  - KronisLV 10mo ago
    > So, assuming the domain of infrastructure-as-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. I think it’s possible to engage with questions like these head on and try to find an answer. The problem is that if you want the answer to be close to accurate, you might need both a lot of input data about the situation (including who’d be working with and maintaining the software, what are their skills and weaknesses; alongside the business concerns that impact the timeline, the scale at which you’re working with and a 1000 other things), as well as the output of concrete suggestions might be a flowchart so big it’d make people question their sanity. It’s not impossible, just impractical with a high likelihood of being wrong due to bad or insufficient data or interpretation. But to humor the question: as an example, if you have a small to mid size team with run of the mill devs that have some traditional OOP experience and have a small to mid infrastructure size and complexity, but also have relatively strict deadlines, limited budget and only average requirements in regards to long term maintainability and correctness (nobody will die if the software doesn’t work correctly every single time), then Go will be closer to an optimal choice. I know that because I built an environment management solution in Go, trying to do that in Rust in the same set of circumstances wouldn’t have been successful, objectively speaking. I just straight up wouldn’t have iterated fast enough to ship. Of course, I can only give such a concrete answer for that very specific set of example circumstances after the fact. But even initially those factors pushed me towards Go. If you pull any number of levers in a different direction (higher correctness requirements, higher performance requirements, different team composition), then all of those can influence the outcome towards Rust. Obviously every detail about what a specific system must do also influences that.
    - Dylan16807 10mo ago
      > It’s not impossible, just impractical with a high likelihood of being wrong due to bad or insufficient data or interpretation. If it's impractical to know, why is using personal preference and intuition a "huge red flag"? That's the core idea being disagreed with, not the idea that you could theoretically with enough resources get an objective answer.

by mjr00 10mo ago

skydhash 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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.
        skydhash 10mo ago
        >> 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.
- KronisLV 10mo ago
  > So, assuming the domain of infrastructure-as-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. I think it’s possible to engage with questions like these head on and try to find an answer. The problem is that if you want the answer to be close to accurate, you might need both a lot of input data about the situation (including who’d be working with and maintaining the software, what are their skills and weaknesses; alongside the business concerns that impact the timeline, the scale at which you’re working with and a 1000 other things), as well as the output of concrete suggestions might be a flowchart so big it’d make people question their sanity. It’s not impossible, just impractical with a high likelihood of being wrong due to bad or insufficient data or interpretation. But to humor the question: as an example, if you have a small to mid size team with run of the mill devs that have some traditional OOP experience and have a small to mid infrastructure size and complexity, but also have relatively strict deadlines, limited budget and only average requirements in regards to long term maintainability and correctness (nobody will die if the software doesn’t work correctly every single time), then Go will be closer to an optimal choice. I know that because I built an environment management solution in Go, trying to do that in Rust in the same set of circumstances wouldn’t have been successful, objectively speaking. I just straight up wouldn’t have iterated fast enough to ship. Of course, I can only give such a concrete answer for that very specific set of example circumstances after the fact. But even initially those factors pushed me towards Go. If you pull any number of levers in a different direction (higher correctness requirements, higher performance requirements, different team composition), then all of those can influence the outcome towards Rust. Obviously every detail about what a specific system must do also influences that.
  - Dylan16807 10mo ago
    > It’s not impossible, just impractical with a high likelihood of being wrong due to bad or insufficient data or interpretation. If it's impractical to know, why is using personal preference and intuition a "huge red flag"? That's the core idea being disagreed with, not the idea that you could theoretically with enough resources get an objective answer.