4 ms·

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 langu

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.

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.