{ home = "/home/bill"
, privateKey = "/home/bill/id_ed25519"
, publicKey = "/home/blil/id_ed25519.pub"
}
{
home = "/home/bill",
privateKey = "/home/bill/id_ed25519",
publicKey = "/home/blil/id_ed25519.pub"
}
I can't tell why a sane person would care much one way or the other, other than the way sane people care about vim vs emacs or tabs vs spaces or Kirk vs Picard...
But regardless, would you think anything new will become mainstream in this space? We already have json, yaml, perhaps a few more. It appears that the problem that the new ones solve start paying off when the software they configure go over some pretty high complexity threshold.
https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...
I wish there was a way to implement more complex validation rules with custom code, although I'm not sure which language that would better be.
crontab is an example that comes to mind, but it uses its own system of date-time patterns. Javascript Date objects wouldnt be suitable.
That doesn't necessarily mean that the language needs dates as a first class data type with a literal syntax etc.
[0] - https://cue.googlesource.com/cue/+/HEAD/doc/contribute.md#st...
The latter is lower friction, in my opinion.
This is especially common for "personal" projects that people end up working on or using on the clock.
I don't know if this was the case with Cue specifically (this is the first I've heard of the project, but less boilerplate in my JSON has some appeal).
*grant a copyright license
I'm sure there is great for someone somewhere doing something but I just see another turtle in the stack...
If you don't have a need for it, perhaps consider it is not for you.
mpvl@ is the main author of borgcfg and one of the two designers of BCL (borg config language). I was maintaining borgcfg 2017-2019, and naturally had occasions to chat with him. I was fortunate to learn the existence of CUE a while ago, and was convinced that its theoretical foundation is solid. That foundation is simply not there in most config languages. CUE (along with Kustomize) appears to me to be the 2 major new ideas of addressing the flaws in BCL, and other template/inheritance-based config languages.
I am very eager to see how the community and industry react to CUE.
Best to avoid this kube+YAML nightmare and go with something with a solid core design. No the Borg paper had no real convince logic in it.
What does this mean?
Are you saying that Borg paper [1] has some arguments for using configuration?
It sounds like you have a good insight around the config mess in infrastructure management.
References: https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...
Disjunctions: https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...
Templates: https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...
Also its looks ugly having even have roon in curlies. Have not look at everything, I am sure Google has its use for this but I think its to much for just configs. And if someone can point why they not just use YAML I would be interested.
Sometimes you might have a legitimate reason to build complex systems out of configs (cloud formation templates, kubernetes, terraform). In that case you might need a bridle to enforce some structure, to keep common things common, and to ensure that variants (such as testing and staging environments) can be expressed in a robust way.
This is something that could generate protobuf values, as you can have expressions and such. Really it does more than protobuf and doesn't handle serialization. It's main use seems to be a config language
At a pervious organization I worked I wrote a Kubernetes manager (docker build + kube config generation + blue/green deploy) that was essentially TOML + Jinja (we we're a python shop). A django + pg + redis app would look like [1].
[1] https://gist.github.com/pnegahdar/1e90f42c1686009e1ff9392b79...
There were definitely some limitations to doing this (some good, like reduced kubernetes surface) but in the end I think we got a large percent of the team writing kubernetes configs through cargo-culting while having generally sane defaults, environment isolation, etc.
I wonder how organizations get people to use these things in a broad way? I'd still be hesitant to write what was described above in something like jsonnet even though it would be much more semantically correct -- I can't imagine getting anyone outside of the ops team to use it!
Generally though, TOML works really well with templating languages (jinja, golang templates, etc) if you include some helper funcs. You can even pass the toml to itself on rendering til you hit a fixed point for references and such.