-
Btw author here, happy to answer / chat about TF stuff. Everyone I spoke to while working on this had some kind of similar issues around representing resources. I’m sure it’s the same here. :-)
-
This is a good article. It showcases some of the rough edges in Terraform usage and gives sign posts as to how to work around them safely.
I think Terraform represents a first step towards the future of configuration management where you model your resources and the tool brings reality into line with that model. We’re doing something like this internally where I work and it’s great.
This is just personal preference but I wish Terraform weren’t written in Go, I find it hard to wrap my head around Go code :)
-
Thanks for the kind words! And there definitely are rough edges. I have a sense that the model isn’t quite right, but haven’t given a lot of thought yet to exactly how.
Re go, it’s pretty easy to read generally. This was maybe my second time programming in Go. The godoc.org site is great too. Docs for everything with links back to the source of functions. Some things are a little underdocumented perhaps, but it’s a handy resource.
-
-
Regarding it being in Go, I think you’re not alone. A scripting language would be more approachable; and with the type checking stuff being added to Python and JS a scripting language could even be more reliable to develop in, too.
-
Interesting. Compared with python I find go much, much easier to read, but very hard to write.
-
-
No, that’s fine. It’s the broader range of idioms (great once you know them), higher frequency of “action at a distance” (decorators, load path mutation etc), higher frequency of code that fails the grep test, and relative difficulty of figuring where a given identifier is defined/modified.
Those things are all tradeoffs that make python easier to write but harder to debug; it’s an excellent language as a result.
-
-
-
-
-
See also: ekam, which is used by sandstorm.io.