3 ms·

Why limit yourself to those types of tools? To protect against somebody writing a non-terminating program? General programming languages come with a lot of ge

Why limit yourself to those types of tools? To protect against somebody writing a non-terminating program? General programming languages come with a lot of general purpose benefits from their ecosystems like package managers npm, cargo, go modules, etc. They have test runners, and control flow. Lots of them already have type definitions for kubernetes and if you are working in Go you have access to almost the entire kubernetes ecosystem. Maybe we are throwing the baby out with the bath water when we disqualify general purpose languages?

verdverm 2y ago
Because people write code that is hard to understand. Configuration doesn't need all that. What it needs is to be provably correct and easy for someone to make predictable changes under high pressure (when prod is down). The non-terminating thing is one of the features of a turing incomplete language, not the goal. You don't want inheritance either, because it becomes hard to know where and when a value gets set (which is what helm overlay via multiple -f uses effectively is) You speak like turning incomplete languages cannot have the control structures, tooling, and ecosystems we enjoy elsewhere, which would be the wrong assessment. I recommend you take a look at CUE to see how this can be true The OpenAPI specs are probably better than the Go language types for k8s. They have more of the validation information and you can get at the CRDs / versions actually running in the cluster.
- davidmdm91 2y ago
  I am not saying that Turing incomplete languages don’t or can’t be a good fit for this task. However there’s no reason we should rule out general purpose languages. We have a lot of configuration based IaC and configuration tooling a la jsonnette and cue and yet these are riddled with their own problems and DX issues. Anyways we don’t need to see eye to to eye on this but I respect your position.
  - mitjam 2y ago
    In addition it is actually hard to not make a template language accidentally Turing complete. Here is an entertaining list of accidentally Turing complete things: https://beza1e1.tuxen.de/articles/accidentally_turing_complete.html https://beza1e1.tuxen.de/articles/accidentally_turing_comple...
  - MrDarcy 2y ago
    > However there’s no reason we should rule out general purpose languages. We’ve learned the hard way general purpose languages are poor for configuration at scale. I know first hand having worked on some of the larger prod infrastructures out there. At scale, the best SRE’s out there still have trouble reasoning about the system and end up pushing bad config that takes down prod. Languages like CUE really are different and better. CUE in particular hits the right balance for configuration of millions of lines of k8s yaml.
    - verdverm 2y ago
      > CUE in particular hits the right balance for configuration of millions of lines of k8s yaml. CUE was created by the same person who wrote the Borg precursor and also worked on BCL & GCL.
    - davidmdm91 2y ago
      I actually really like CUE. I use it kind of extensively as a YAML replacement where I can, and at my work we've done our best to integrate cue with our charts to validate the values used to invoke our charts and to unify the value space. However there's something about a full blown general purpose language that is so much more flexible. I don't think that the fact that people can and do write bad programs disqualifies general purpose languages from being great tools to build packages. I am sure there is just as equally bad CUE, Jsonette, PKL, etc out there. Other than CDK8s I don't know of other tools that have tried in this space to use general purpose languages to define their packages, and I think CDk8s uses are generally happy. Much more so than helm users at least. I am not sure I can agree with this statement > We’ve learned the hard way general purpose languages are poor for configuration at scale I think we've just assumed this, or seen a pulumi project we didn't like working in. I believe and hope there will be plenty of room to experiment and innovate in this space!
      - verdverm 2y ago
        The difference is in shared understanding. With tools like CUE or Starlark, you can learn one system and everyone can reason across each other's work. With imperative languages, every instance is a snowflake and creates significant mental overhead. It's the flexibility that is actually the problem for configuration. I get there is/was a trend towards general purpose languages in DevOps, but I think we are post peak on the adventure.

verdverm 2y ago

Because people write code that is hard to understand. Configuration doesn't need all that. What it needs is to be provably correct and easy for someone to make predictable changes under high pressure (when prod is down). The non-terminating thing is one of the features of a turing incomplete language, not the goal. You don't want inheritance either, because it becomes hard to know where and when a value gets set (which is what helm overlay via multiple -f uses effectively is) You speak like turning incomplete languages cannot have the control structures, tooling, and ecosystems we enjoy elsewhere, which would be the wrong assessment. I recommend you take a look at CUE to see how this can be true The OpenAPI specs are probably better than the Go language types for k8s. They have more of the validation information and you can get at the CRDs / versions actually running in the cluster.

davidmdm91 2y ago
I am not saying that Turing incomplete languages don’t or can’t be a good fit for this task. However there’s no reason we should rule out general purpose languages. We have a lot of configuration based IaC and configuration tooling a la jsonnette and cue and yet these are riddled with their own problems and DX issues. Anyways we don’t need to see eye to to eye on this but I respect your position.
- mitjam 2y ago
  In addition it is actually hard to not make a template language accidentally Turing complete. Here is an entertaining list of accidentally Turing complete things: https://beza1e1.tuxen.de/articles/accidentally_turing_complete.html https://beza1e1.tuxen.de/articles/accidentally_turing_comple...
- MrDarcy 2y ago
  > However there’s no reason we should rule out general purpose languages. We’ve learned the hard way general purpose languages are poor for configuration at scale. I know first hand having worked on some of the larger prod infrastructures out there. At scale, the best SRE’s out there still have trouble reasoning about the system and end up pushing bad config that takes down prod. Languages like CUE really are different and better. CUE in particular hits the right balance for configuration of millions of lines of k8s yaml.
  - verdverm 2y ago
    > CUE in particular hits the right balance for configuration of millions of lines of k8s yaml. CUE was created by the same person who wrote the Borg precursor and also worked on BCL & GCL.
  - davidmdm91 2y ago
    I actually really like CUE. I use it kind of extensively as a YAML replacement where I can, and at my work we've done our best to integrate cue with our charts to validate the values used to invoke our charts and to unify the value space. However there's something about a full blown general purpose language that is so much more flexible. I don't think that the fact that people can and do write bad programs disqualifies general purpose languages from being great tools to build packages. I am sure there is just as equally bad CUE, Jsonette, PKL, etc out there. Other than CDK8s I don't know of other tools that have tried in this space to use general purpose languages to define their packages, and I think CDk8s uses are generally happy. Much more so than helm users at least. I am not sure I can agree with this statement > We’ve learned the hard way general purpose languages are poor for configuration at scale I think we've just assumed this, or seen a pulumi project we didn't like working in. I believe and hope there will be plenty of room to experiment and innovate in this space!
    - verdverm 2y ago
      The difference is in shared understanding. With tools like CUE or Starlark, you can learn one system and everyone can reason across each other's work. With imperative languages, every instance is a snowflake and creates significant mental overhead. It's the flexibility that is actually the problem for configuration. I get there is/was a trend towards general purpose languages in DevOps, but I think we are post peak on the adventure.