I've used Terraform quite a bit (though less in the past year), and the things that ended up being the biggest headaches for me were:

1. State quickly gets unwieldy and terraform plans get very slow. I think the official recommendation is to split it up to separate instances using separate state files, but that adds complexity of finding the right seams and sharing any needed data between them.

2. Desperately needs a good way to do singletons. Many modules end up fitting the pattern that you need 1 each of some underlying resources (iam role, iam policy, s3 bucket, kms key, whatever) that could be shared by every instance of the thing you're creating. But you have to decide between keeping the code clear and organized and putting those things in the module next to the resources that rely on them, but then duplicating these things N times unnecessarily (which adds to the problem of bloated, slow state). Or you keep the shared resource outside of the module, which makes the code less clear, bloats the global namespace/tf files and requires passing around even more state variables to the module.

3. Tools for abstractions and structuring the app are lacking in general in other ways. Modules are the only thing you have and they were intended to be standalone for sharing code externally and are clunky when using them only within your own app to organize code. There's no way to import shared constants or even group related variables together into something like structs, so you end up needing to pass around the same handful of individual variables into almost every module and resource you create.

4. Your whole terraform config is only as stable as the worst implemented resources. I think this problem is even worse for smaller, community support-only providers but even within AWS, it's not uncommon to come across bugs in how different services are integrated into terraform. Sometimes useful parameters are missing, or terraform doesn't validate them the same way as AWS itself causing something in your apply to fail halfway through, or things are implemented such that the subsequent tf plan still doesn't show up clean after a successful apply. TF has gotten more stable over time, but there still seems to be an endless long-tail of leaky abstraction type issues like these.

This turned into kind of a long list of gripes, but I'd be very curious to hear from anyone who has used both Pulumi and Terraform in production how Pulumi compares on these painpoints in particular.

> 1.

Start with one per environment. As it grows, you can identify the reusable patterns and move those to their own state files and import them wholesale with terraform_remote_state. It's code, treat it like code.

> 2.

A module for shared resources, a module for resources that use them. You don't bloat anything if you just namespace it and then pass the shared resources' output as an entire object to a parameter in the resources that share them.

> 3.

Same answer. You can create objects for your outputs where you can easily namespace things.

> 4.

This is true. But there's no better way for obvious reasons. It's a high level abstraction, the only alternative is to use low level abstractions, at which point you're just doing shell scripts. Which, by the way, Terraform has pretty clever ways to integrate. It's not pretty, but it's isolated ugliness much like unsafe Rust/C# where you really need to instead of having to go full ugly.

Also, you can always submit pull requests to Terraform providers. Doesn't guarantee the maintainers will be active enough to respond and upstream it, but it will solve the issue cleanly for you and other people at least in the meantime.