4 ms·
The cycle of tooling Step 1: Look I've made this new great tool that uses a declarative language, you simply declare what you want your environment to look lik
by gustavus 3y ago
The cycle of tooling
Step 1: Look I've made this new great tool that uses a declarative language, you simply declare what you want your environment to look like and boom it will build it out. No more having to figure out a complicated logic flows that can fail or having code that dies on weird error cases, and you don't have to be a developer to use it.
Step 2: The tool isn't powerful or flexible enough and the declarative code is getting to cumbersome so we've introduced some basic templating and logic flow to this tool to make it more flexible and reduce bloat.
Step 3: The control flow isn't powerful enough to really meet our needs so we have moved it entirely to a full programming language.
Step 4: Go back to step 1.
- aknfxb3m 3y agoSteps 1,2,3 create separate solutions that people can use as they see fit. You make it seem like there is no place for anything but a declarative programming language in this area.
- hitchstory 3y agoIt's often better to provide both - especially for something like k8s. Declarative languages and programming languages serve entirely different use cases. They no more preclude each other than garbage collected and non garbage collected programming languages like C and python do.
- jacurtis 3y agoTo be fair... k8s offers both: Write declarative code with yaml and kubectl. This solves most use cases and interactions. Write operators in a variety of languages (usually golang) if you need direct control of the underlying control loop, advanced resources, and other use cases to extend or customize how your cluster works. This is far more flexible and powerful than most people understand and of itself has layers ranging from moderate to very complex. Furthermore there is the api aggregation layer you can extend if you need to customize the core api of your cluster.
- deleted 3y ago[deleted]