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/
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.
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
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.
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?
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.
9 comments
[ 4.1 ms ] story [ 30.6 ms ] threadFor other people: I'm pretty sure the author is talking about https://cuelang.org/
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.
> [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
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.
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.
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?
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