https://leebriggs.co.uk/blog/2023/09/04/dsl
If you’ve read this blog before, or are unfortunate enough to have an actual personal relationship with me, you’ll know that I have strong opinions and can be, shall we
TLDR: terraform bad, pulumi good
Pulumi code ends up looking like a DSL anyway with all the stuff you end up using from the top-level pulumi package to do anything vaguely complicated.
Only now, compared with Terraform, you need to worry about resource ordering and program flow, because when you have a dependency between resources, the resource object you depend on has to be instantiated (within the program flow, I mean - Pulumi handles calculating the ordering of actual cloud resource creation) before the dependent resource. This gets old really quickly if you're iterating on a module that creates more than a few interdependent resources. So much cut, paste, reorder. FWIW CDK has the same issue, and for the same reason - because it's using a general-purpose programming language to model a domain which it doesn't fit all that well.
I like Pulumi and it's got a lot going for it, especially if you have complex infrastructure requirements. You get a bunch of little quality of life enhancements that I wish Terraform would adopt, like cloud state management by default, and a built-in mechanism for managing secrets in a sane way. Python/TypeScript etc. modules are much more flexible than Terraform modules, and really help with building large chunks of reusable infrastructure. The extra programmability can be useful, though you need to be extra-careful of side-effects. You get more power, but you also get some extra work.
But for most people deploying a bit - or even quite a lot - of cloud infrastructure, Terraform is honestly just easier. It's usually some fairly simple declarative config with some values passed from one resource to another, and a small amount of variation that might require some limited programmability. Which is exactly what Terraform targets with HCL. It's clear to me that Pulumi sees this too, since they introduced the YAML syntax later on. But IMO HCL > YAML for declarative config.
Damn people need to stop using acronyms in titles. My first thought was Digital Subscriber Lines are not a waste. They are very much needed in many parts of the world where phone lines are the current cable into the house and fibre has not been built to the home yet.
I don't think DSLs are a waste of time, just a stepping stone in a quite new IT paradigm. A lot of things will die until IaC stabilizes.
I'm more fearing ever increasing reliance on Cloud Providers. Trust and power that we are giving these companies is getting insane and I hope I'm wrong but it will bite all of our butts big time. I hope all of IaC tools will create more tools to have better power balance.
I thought I was going to disagree at first, because I am forced to use multiple DSLs for several projects I work on, however after I thought about it I hate the those DSL's because they are not actual programming languages they are overly restrictive. more limiting than assembly, thus why I am using an actual language to create my own DSL that mainly uses the language as its host, so its not really a full DSL just a few extra functions on top of an actual language. so surprisingly I pretty much agree.
I would say Elixir, Ocaml, Rust, Haskell, Scheme, Clojure, Common Lisp all have great examples of large and small DSL's that are very convenient, I would also include libraries as DSLs a C example would be something like Raylib, or SDL, and I would consider the code below an example of a micro DSL in Common Lisp.
(loop for i from 0 to 100 by 2
for x from 10 by 10
do (print (list i x)))
so I think I mostly agree.
10/10. At my last job, we switched from a custom DSL to plain old Python and haven't looked back.
Here's my opinion, a well-developed DSL could even be arguably more flexible than say Python even with existing libraries on their specific domains. So, if one is just limited to domains, they may be very well be preferable to general languages.
I have coded in C#, Python, C++, and currently nearly everyday, G'MIC. Which one of those are a DSL? The last one. What it is? It's a Domain-Specific Language that has been geared toward raster graphics image processing. Why do I use it? Looking at the stack-based processing, commands, built-in mathematical functions. It seems that it has a lot more things that are built-in than say Pillow library for Python and other things. And I only do create images with code, so I am happy with this, and I even did things like Python itertools combinatorics with more things like rank2list/list2rank variation of those combinatorics which aren't image processing by themselves, but can aid to it.
If I feel that it is way too limited for that Domain, then I wouldn't use it. DSLs are only good if the other options are much more difficult to build with and their flexibility are often enough to entice their audience which is one with limited use cases. Of course, generic languages are usually better even than most DSL even within their domains because of wider support, and wider audience. More DSLs would be better than generics given enough time and support for their domains in my opinion.
Lua fall into that category too. It can be embedded to allow writing plugins or extensions.
LUA is a programming language. Being embeddable doesn't stop something from being a DSL. It's not an attribute that should factor in the distinction between DSL and general purpose programming language.
Ok i think i get the point. A "generic programming language" could be used as a "domain specific language" in some context. Is that what you mean?
The author is actually fine with CDK, since it uses an actual programming language. That's the point of the article.
By the way, on a personal note, Terraform is still bad to my eyes since their license change.
The author looks a bit uninformed
My sincere hope is that either Terraform or the OpenTF folks decide to invest in the CDK model.
because such a model is already here and it's cdktf. That's my point.
The rest of the article looks like a rant about the need of making choices and learning new stuff, which is meh at least
The author seems fully aware of the existence CDKTF, and by invest i think he means that they should privilege it instead of HCL. The point is that if you learn Python, it is reusable somewhere else. If you learn HCL, you learned a vendor language, it is only used in Terraform.
yeah well duh, I did catch the point, it's pretty understandable. But that's a silly point, there is plenty of ignorant nerds already, no real need for ignorant lazy nerds
Yeah we are better served with pedantic nerds that thinks they know IaC better than some top engineer at an IaC vendor 🤷