3 ms·

> My recommendation is to make your choice based on the merits of the options, rather than trying to keep up with the latest trend. It's not a matter of keepin

> My recommendation is to make your choice based on the merits of the options, rather than trying to keep up with the latest trend. It's not a matter of keeping up with the latest trend, it's a matter of moving a whole org to a technology or project that gets killed off. There are real costs to making the wrong choice. > If nothing else, it will make you smarter, and that will make you more conscious, and that will make you more alive. Which is great if you're talking about a personal project but if you're setting strategy for an org or team then you need a better metric than "how alive does it make you feel."

dqpb 5y ago
It’s an open source library, not a service. So if you fork it, it can’t be killed off.
- verdverm 5y ago
  The creator Marcel left Google to work on CUE full-time, and created an independent foundation. https://twitter.com/mpvl_/status/1412793623381516294 https://twitter.com/mpvl_/status/1412793623381516294
ra7 5y ago
> Which is great if you're talking about a personal project but if you're setting strategy for an org or team then you need a better metric than "how alive does it make you feel." I don't think GP meant you base your strategy on "how alive Cue makes you feel". They simply meant the concepts are a good read and having read the Cue documentation before, I agree with it.
verdverm 5y ago
CUE is something that can augment your existing tools. You don't have to replace them. You can adopt incrementally to add confidence where you find repeated configuration mistakes. If you want to validate your configuration with concise schemas, then you can use it like JSON Schema, even importing your existing schemas and making them readable. CUE will make you think about the structure and taxonomy of your configuration / data. If anything, this is a good exercise that can make your code better even if you don't end up adopting CUE.
- atombender 5y ago
  Yes, but if you move all your stuff to Cue, you've committed to it for a while. My company has tons of apps on Kubernetes: Currently around 2,200 resources totaling more than 100,000 lines of YAML. And we're not a big organization. But once migrated, even an org our size is going to find it hard to migrate to something else.
  - verdverm 5y ago
    Being snarky, I'd say you won't look back if you did migrate. Again, you could just place CUE next to Yaml to validate it. You can always write the yaml version to disk from CUE. CUE will also read and import your Yaml so that you don't have to rewrite it by hand. It would certainly be harder to migrate away from something like Starlark or Pulumi where config is wrapped in code. 3rd party tooling is much harder to write under that paradigm. Marcel, the creator of CUE, wrote the prototype that became Borg and eventually Kubernetes. He was also on the teams that wrote the config languages for these systems. Your use case has been central to CUE's design.

dqpb 5y ago

It’s an open source library, not a service. So if you fork it, it can’t be killed off.

verdverm 5y ago
The creator Marcel left Google to work on CUE full-time, and created an independent foundation. https://twitter.com/mpvl_/status/1412793623381516294 https://twitter.com/mpvl_/status/1412793623381516294

ra7 5y ago

> Which is great if you're talking about a personal project but if you're setting strategy for an org or team then you need a better metric than "how alive does it make you feel." I don't think GP meant you base your strategy on "how alive Cue makes you feel". They simply meant the concepts are a good read and having read the Cue documentation before, I agree with it.

verdverm 5y ago

CUE is something that can augment your existing tools. You don't have to replace them. You can adopt incrementally to add confidence where you find repeated configuration mistakes. If you want to validate your configuration with concise schemas, then you can use it like JSON Schema, even importing your existing schemas and making them readable. CUE will make you think about the structure and taxonomy of your configuration / data. If anything, this is a good exercise that can make your code better even if you don't end up adopting CUE.

atombender 5y ago
Yes, but if you move all your stuff to Cue, you've committed to it for a while. My company has tons of apps on Kubernetes: Currently around 2,200 resources totaling more than 100,000 lines of YAML. And we're not a big organization. But once migrated, even an org our size is going to find it hard to migrate to something else.
- verdverm 5y ago
  Being snarky, I'd say you won't look back if you did migrate. Again, you could just place CUE next to Yaml to validate it. You can always write the yaml version to disk from CUE. CUE will also read and import your Yaml so that you don't have to rewrite it by hand. It would certainly be harder to migrate away from something like Starlark or Pulumi where config is wrapped in code. 3rd party tooling is much harder to write under that paradigm. Marcel, the creator of CUE, wrote the prototype that became Borg and eventually Kubernetes. He was also on the teams that wrote the config languages for these systems. Your use case has been central to CUE's design.