4 ms·

Is there anyone out there that has actually, in the real world, realized CUE's promise of bundling type safety + data/configuration + task running in such a way

by solatic 9mo ago

Is there anyone out there that has actually, in the real world, realized CUE's promise of bundling type safety + data/configuration + task running in such a way that does not require wrapping it in shell scripts? Can you set up your CI/CD pipelines so that it's literally just invoking some cue cmd, and have that cmd invocation be reasonably portable? The problem is, once you have to wrap CUE, the loss of flexibility within a special-purpose language like CUE is enough for people to ask why not just bother writing the scripts in a general purpose language with better ecosystem support. And that's a hard sell in corporate environments, even ones that find benefit in type safe languages in general, because they can just pick a general purpose language with a static type checker.

CuriouslyC 9mo ago
Cue.js has a wasm port. I really like cue for my spec driven development tool Arbiter, it is great for structured specs because it acts like a superset of most configuration/programming languages.
maccard 9mo ago
I can't speak for CUE, but I've worked with CI and "build orchestration tools"in the past. Most CI providers provide executor APIs that let you override it as a plugin. One example is https://buildkite.com/resources/plugins/buildkite-plugins/docker-buildkite-plugin/ https://buildkite.com/resources/plugins/buildkite-plugins/do... - you mark this as "this is using docker" and configure it in the environment, and then you provide the command. You need to be very careful about the design of the plugin, but I've done it a few times and it's viable.
mxey 9mo ago
Not sure if that’s what you mean but we have apps where all you need to deploy them to Kubernetes is run “cue cmd deploy”. > The problem is, once you have to wrap CUE, the loss of flexibility within a special-purpose language like CUE is enough for people to ask why not just bother writing the scripts in a general purpose language with better ecosystem support. cue cmd is nice but it’s not the reason to use CUE. The data parts are. I would still use if I had to use “cue export” to get the data out of it with a bit of shell.
- solatic 9mo ago
  > Kubernetes So cue cmd also built the image, authenticated to a private registry, pushed the image, authenticated to the private Kubernetes cluster, and ran kubectl apply?
  - mxey 9mo ago
    No, that’s why I said deploy. All it does is run kubectl apply and kubectl rollout status. Only those are directly tied to the data in CUE. there’s not much advantage to running other commands with it. You can run arbitrary processes with cue cmd though.
    - solatic 9mo ago
      Yeah but that's kinda my point. OK you can write policy to control the Kubernetes configuration with CUE. What about policy to control the Dockerfile, let alone the policy to control the cloud infrastructure? No? So the Security folk writing policy need to learn two languages - one for general-purpose policy, plus CUE specifically for Kubernetes manifests? Why not write the policy for Kubernetes manifests in the general-purpose language they're using for the rest of the policy? And so on and so forth, which make CUE's value proposition dubious in the enterprise.
teh 9mo ago
I can't fully answer your question but I did once spend about a week porting plain internal configuration to cue, jsonnet, dhall and a few related tools (a few thousand lines). I was initially most excited by cue but the novelty friction turned out to be too high. After presenting the various approaches the team agreed as well. In the end we used jsonnet which turned out to be a safe choice. It's not been a source of bugs and no one complained so far that it's difficult to understand its behaviour.

by solatic 9mo ago

CuriouslyC 9mo ago

Cue.js has a wasm port. I really like cue for my spec driven development tool Arbiter, it is great for structured specs because it acts like a superset of most configuration/programming languages.

maccard 9mo ago

I can't speak for CUE, but I've worked with CI and "build orchestration tools"in the past. Most CI providers provide executor APIs that let you override it as a plugin. One example is https://buildkite.com/resources/plugins/buildkite-plugins/docker-buildkite-plugin/ https://buildkite.com/resources/plugins/buildkite-plugins/do... - you mark this as "this is using docker" and configure it in the environment, and then you provide the command. You need to be very careful about the design of the plugin, but I've done it a few times and it's viable.

mxey 9mo ago

Not sure if that’s what you mean but we have apps where all you need to deploy them to Kubernetes is run “cue cmd deploy”. > The problem is, once you have to wrap CUE, the loss of flexibility within a special-purpose language like CUE is enough for people to ask why not just bother writing the scripts in a general purpose language with better ecosystem support. cue cmd is nice but it’s not the reason to use CUE. The data parts are. I would still use if I had to use “cue export” to get the data out of it with a bit of shell.

solatic 9mo ago
> Kubernetes So cue cmd also built the image, authenticated to a private registry, pushed the image, authenticated to the private Kubernetes cluster, and ran kubectl apply?
- mxey 9mo ago
  No, that’s why I said deploy. All it does is run kubectl apply and kubectl rollout status. Only those are directly tied to the data in CUE. there’s not much advantage to running other commands with it. You can run arbitrary processes with cue cmd though.
  - solatic 9mo ago
    Yeah but that's kinda my point. OK you can write policy to control the Kubernetes configuration with CUE. What about policy to control the Dockerfile, let alone the policy to control the cloud infrastructure? No? So the Security folk writing policy need to learn two languages - one for general-purpose policy, plus CUE specifically for Kubernetes manifests? Why not write the policy for Kubernetes manifests in the general-purpose language they're using for the rest of the policy? And so on and so forth, which make CUE's value proposition dubious in the enterprise.

teh 9mo ago

I can't fully answer your question but I did once spend about a week porting plain internal configuration to cue, jsonnet, dhall and a few related tools (a few thousand lines). I was initially most excited by cue but the novelty friction turned out to be too high. After presenting the various approaches the team agreed as well. In the end we used jsonnet which turned out to be a safe choice. It's not been a source of bugs and no one complained so far that it's difficult to understand its behaviour.