[dmattia]

You would have separate JS and Python stacks that could share outputs, similar to a `terraform_remote_state` data source in terraform-land. There's also a yaml "language" support if you just want to use a config language: https://www.pulumi.com/docs/intro/languages/yaml/, but I have never messed with this, as we really just use typescript.

As somebody who maintains public terraform providers though, I do want to point out that "With TF, there is one language and one binary" is not totally accurate. Each provider you install must be installed separately, and runs separately as its own process, and the core terraform library calls out to the providers via gRPC. You can verify this by running `ps` during your next terraform run and seeing all the different providers on their own processes.

Pulumi actually uses the same gRPC setup, and can even communicate with Terraform providers. So the only real different part binary wise is the "core" terraform binary being replaced by a different "core" pulumi binary based on the language you are using, but the rest of the providers will all be the same, and you'll run multiple languages either way.

If your company only supports one or a few languages in your normal production code, you can also just use those languages for Pulumi, and still get one language and one binary. There's nothing forcing you to use multiple different languages.

[verdverm]

It's still an extra dimension of complexity to support N language runtimes. Won't each of them still need the same TF providers?

With TF, sure there is a call to fetch those providers & modules, but still, I don't have to install N language runtimes, which needs its own IaC to build, thus adding another process to the mix

I would assume most eng orgs try to limit their Pulumi to one language to skirt this issue