Hacker News Reader

> code should be optimised to be easy to READ

You say that as if it’s impossible to write clear code. As soon as you have any form of multiple resources (e.g. create x of y) I’ll take the real programming language over terraform.

> As soon as you have any form of multiple resources

terraform handles this with for_each. need 10 EBS volumes on 10 EC2 instances? for_each and link instance id of the each value. done. theres a bunch of stuff i now don’t have to worry about (does the instance actually exist yet? other validation edge cases?)

https://developer.hashicorp.com/terraform/language/meta-argu...

> You say that as if it’s impossible to write clear code.

not the parent, but i feel their usage of the word “code” was in error. i don’t care about how, i care about what.

the HCL is purely a defintion/description of what the infrastructure looks like. what resources will be created? that is all it is. i want that. to define the infra and move on. i don’t want low level control of every minutia to do with infrastructure. i want to read a config file and just know what resources will exist in the account. wanna know every resource that exists? `terraform state list` … job done. no reading code required.

HCL/terraform is to define my cloud resources, not to control them or their creation. if i want control, then i need to whip out some go/python.

that’s my vibe on CDK libraries/platform APIs versus terraform.

I don’t understand how these things follow.

I’ll be the first to agree that CDK sucks, but Pulumi is essentially Terraform as a programming language, with all the niceties of terraform and more besides.

The format that defines what infra looks like is… very hard to parse with terraform (for me). It seems optimized for defining a list of static resources, and everything else is bolted on. The for_each or count constructs do not make intuitive sense to me anyway.

That said, by all means, use Terraform, as long as it’s not CDK I’ll be happy.

You can understand every single terraform codebase using nothing other than the terraform documentation itself. All abstractions are provided by the language itself.

Clear isn't really the word I would call it, more that the real work being done is exposed and always visible.

Modules aren’t provided by the language though?

Fortunately, Terraform has CDKTF [1] which allows you to use common languages such as Python, Java, and TypeScript to author Terraform infra.

I used it daily and find it greatly liberating.

[1] https://developer.hashicorp.com/terraform/cdktf

>whoever comes across your clever code next will probably want to hit you, especially if it's not a dev from your immediate team, and especially if you have succumbed to blurring the lines between your idk code and your app code.

If you want to maximize the number of people who have a chance of understanding what is happening, python is your huckleberry. They are going to want to hit the guy who wrote everything in a bizarre language called HCL that nobody outside of infra has ever seen or heard of.

> If they instead come across some bog-standard terraform that maybe has a bunch of copy-paste and is a bit more verbose... Who cares? Its function will be obvious, there is no mental overhead needed.

"bog standard" is doing a lot of heavy lifting here. You can write simple python or esoteric python and you can write simple terraform or esoteric terraform.

As the Go proverb goes: "clear is better than clever". https://go-proverbs.github.io/