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?
For other people: I'm pretty sure the author is talking about https://cuelang.org/
Yes, he means that CUE.
CUE seems like the opposite: a typed data structure used to produce artifacts via a unification algorithm.
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.
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.
> 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.
> [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
> 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.
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/