hckrnws

Please, please - just link to the actual "CUE" project. Not everyone has heard of your favourite thing. The first reference to `CUE` should be a hyperlink.

For other people: I'm pretty sure the author is talking about https://cuelang.org/

And that black code markup is really annoying.

Yes, he means that CUE.

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.

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.

> 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?

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.

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.

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.

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.

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.

Coincidentally, I recently looked at using CUE as a config file format, but it looked like it was too syntactically complex and unwieldy for them to edit compared to, say, TOML (which is warty-but-usable) or YAML (which is incredibly complex and has too many footguns).

Also, in order to work with it and to understand why their configs weren't working beyond simple error messages or worse, a config file that is technically correct but does something they don't want. To do that, if seems like they'd have to (a) understand unification, (b) be able to find and read the spec files, (c) overcome the syntactic similarity between data and schema, (d) be able to build mental models of why the data and schema combine to cause the symptoms they have. I decided to not use it for that purpose (yet).

I _want_ something like CUE, which is why I was looking at it, so...

Does anyone here have any real-world experience using it as a config and/or data format and ingestion engine for users that are _not_ complexity-loving CS-ophiles like myself who love nothing more than a cool new way of munging data?

You make it sound like unification / cue's model has some unnecessary complexity but the reality is that unification is very intuitive and whole model is one of the best (formalized!) ideas at _simplifying_ configs/data generation/transformation/validation.

Their docs are very approachable, consumable in single evening.

I like CUE a lot. We use it pretty heavily for schema enforcement of CRDs. That being said, it is pretty complex and learning to use it was anything but straight forward.

For more basic configs, I would potentially look into KCL https://www.kcl-lang.io/

It has a much simpler usage overall especially if you are only really trying to enforce some config rules.

The other alternative is to just use whatever language you are writing your software in and build a basic validator

I'm so bullish on CUE. It seems like it's really solving the "code as configuration" problem properly and I think there are lots of other upside use cases around general data defintion components of it that make for typesafe authoring.

The fundamental idea of CUE (quoting them) "enable[s] data, schema, and policy constraints to coexist seamlessly" is really amazing for some use cases. But from a practical / DX perspective, the language seems pretty awkward and hard to understand. Dump someone who hasn't seen cue before into some complex cue files and they are definitely reading the docs to try to understand what is happening...

We built a similar kind of system with a much more limited scope - for handling environment variables, that is much more ergonomic IMO. It uses .env files with decorator style comments and new function call syntax to mix schema, default values, declarative instructions on how to fetch data, internal references, merging multiple definitions.

Check it out at https://varlock.dev

ELI5 how this is Literate Programming? See the first example on https://en.wikipedia.org/wiki/Literate_programming for comparison.

CUE seems like the opposite: a typed data structure used to produce artifacts via a unification algorithm and feeding data to external tools to "render" those artifacts.

The same thing I wonder when one claims Jupyter notebooks to be literate programming.

I think cue might be close but to be honest, some practical examples would have been helpful to get a better impression of the point the article is trying to make.

The writing style smells like Gemini output. I din't mind, I just wonder if anyone else noticed.

Maybe it's unfair, unhelpful or overdone to call out llmisms, but if OP is reading this I stopped reading pretty quickly as a result of things like:

> [CUE] does not just hold the text; it validates that the pieces actually fit. It ensures that the code in your explanation is the exact same code in your final build. It is like having a Lego set where the bricks refuse to click if you are building something structurally unsound.

And that's despite having a passing interest in both cue and LP

> Maybe it's unfair, unhelpful or overdone to call out llmisms

Not anywhere near as overdone as posting AI generated/revised articles to HN that are an absolute slog to read.

A real shame, honestly, because the other article[1] from this blog that made it to the front page recently was good. The difference in writing style between them is striking, and I think it serves as a really good example of why I just can't stand reading AI articles.

[1] https://xlii.space/eng/i-hate-github-actions-with-passion/

Ah, the negative positive construction. Another casualty of the anti-AI movement. The semicolon was almost certainly inserted manually in place of an em-dash, models almost never use them.

Accusing people of using generative AI is definitely one of those things you have to be careful with, but on the other hand, I still think it's OK to critique writing styles that are now cliche because of AI. I mean come on, it's not just the negative-positive construction. This part is just as cliche:

> It is like having a Lego set where the bricks refuse to click if you are building something structurally unsound.

And the headings follow that AI-stank rhythmic pattern with most of them starting with "The":

> The “Frankenstein” Problem

> The Basic Engine

> The Ignition Key

> The Polyglot Pipeline

I could go on, but I really don't think you have to.

I mean look, I'm no Pulitzer prize winner myself, but let's face it, it would be hard to make an article feel more it was adapted from an LLM output if you actually tried.