alt Hacker NewsIs 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.
Replies
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.
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/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.
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.
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.