I really don’t think that was ever in doubt. You only need to use it for a very short time to find that the ergonomics are infinitely nicer than Terraform.

My biggest issue with terraform is concept of state file. It seems that Pulumi continues on this model. I wish someone came up with innovative idea of not needing state file.

this is difficult for me to think about in the same way as trying to picture a 4th dimension.

surely, state needs to be tracked somehow. what would an alternative even be?

> this is difficult for me to think about in the same way as trying to picture a 4th dimension.

Why? There are many possibilities, just not that efficient. One of them would involve tagging. The problem with that approach is that not all resources are taggable, and it would take longer to query them.

tagging provider resources? not speaking for every provider or api, but at least on AWS not everything that can be managed supports tagging.

also this requires N api calls each time you check the state for an update. scaling that to a larger team may be difficult due to rate limits.

infra as code tools have to operate within the parameters that the provider apis allow. so when i say it’s hard to imagine, i’m thinking about limitations of the underlying apis.

totally possible im missing something obvious, but there’s a good reason that centralized state exists today. genuinely curious about how we could ditch it in a reasonable way with the existing big cloud APIs.

Querying the cloud provider apis for current state? Go to the actual source of truth?

I'm sure there are complications i don't care to see here, but why is "this is what is actually deployed" not the default case?

Querying cloud provider API’s takes a while. It can be done, but the results are cached afterwards, which is the state file.

Refreshing the state file (and reconciling differences) also uses the cloud provider API’s. I don’t think we’re going to get better than that.

Unless someone makes a common standard for resource reporting that all cloud providers implement.

The state file is more than a cache. If it was just a cache, it wouldn't be problematic.

exactly. relying purely on the provider’s api seems like an untenable solution with the current state of things.

you’d be subject to rate limits and all manner of potential issues and outages if you only query the providers api.

that’s part of the case for a centralized state, to have an additional place that describes what should exist and what it looks like.

Bicep does that, but it's Azure only, and you can't really 'destroy', just apply.

From my prelimary search, Bicep does utilize a state file, but it is completely hidden from the end users. Seems to be managed in Azure directly and automagically.

https://learn.microsoft.com/en-us/azure/azure-resource-manag...

I think you might be misunderstanding this page. Bicep's "state file" is actual Azure state. Bicep is a nicer way to write ARM (Azure Resource Manager), which is pretty much an Azure API. if you are familiar with Kubernetes, ARM represents Azure internal state in the same way kubernetes YAML represents actual kubernetes objects stored in the cluster.

> No state or state files to manage: All state is stored in Azure. Users can collaborate and have confidence their updates are handled as expected.

Not sure how I could "misunderstand" this quote to mean anything else.

By that logic, CloudFormation is also the same; end users don't have access to the state so therefore the state file is the state of the environment itself? We, as users, have no idea what intermediate step exists between the configuration yaml and actual representation of an account's resources.

<3 pulumi