Because of that bucket of problems people end up using these tools to manage terraform runs (also known as TACOs). Terraform Cloud is one of them; there's also Spacelift, Atlantis and a bunch of others covering various aspects of what terraform the language doesn't handle natively (ci/cd, state, tfvars management, dependencies, etc).
At the core though, this seems to boil down to a multi-graph comprised of states with some extra stateful pieces on top, like TFVars, inputs/outputs etc. All that's needed is a reliable service that manages these stateful bits in a manner that supports security and compliance needs (secrets stored safely, audit trail, etc). Currently all that is either not there at all, or part of a large "package offering" like Terraform Cloud or Spacelift.
The case I'm making is that this "logical core" needs to exist in a way that's not coupled to a do-it-all cloud-based solution. It probably should not be part of the language itself; but also shouldn't be an all-or-nothing proposition. Hence the VM / runtime parallel
Another parallel to express a similar concept could be "instrumentation for terraform" - it'd be odd if all the observability tooling for a particular language (say Java) were coupled to a cloud-based offering by the company that created said language (Oracle) right? There's a bunch of stuff outside of Java that most Java applications need nevertheless - like application server (eg Tomcat) and so on. Okay that's not exactly instrumentation; but then logging tools, monitoring tools, etc.
Because of that bucket of problems people end up using these tools to manage terraform runs (also known as TACOs). Terraform Cloud is one of them; there's also Spacelift, Atlantis and a bunch of others covering various aspects of what terraform the language doesn't handle natively (ci/cd, state, tfvars management, dependencies, etc).
At the core though, this seems to boil down to a multi-graph comprised of states with some extra stateful pieces on top, like TFVars, inputs/outputs etc. All that's needed is a reliable service that manages these stateful bits in a manner that supports security and compliance needs (secrets stored safely, audit trail, etc). Currently all that is either not there at all, or part of a large "package offering" like Terraform Cloud or Spacelift.
The case I'm making is that this "logical core" needs to exist in a way that's not coupled to a do-it-all cloud-based solution. It probably should not be part of the language itself; but also shouldn't be an all-or-nothing proposition. Hence the VM / runtime parallel
Another parallel to express a similar concept could be "instrumentation for terraform" - it'd be odd if all the observability tooling for a particular language (say Java) were coupled to a cloud-based offering by the company that created said language (Oracle) right? There's a bunch of stuff outside of Java that most Java applications need nevertheless - like application server (eg Tomcat) and so on. Okay that's not exactly instrumentation; but then logging tools, monitoring tools, etc.