Project status?

[joshburkart]

Hi,

Cue seems like a really interesting language! My team may be on the lookout for a solid config language, so I'd love to learn more about it. I'm having trouble assessing the project's status/maturity, though -- could someone please comment? Specifically wondering:

1. How many engineers have contributed to its specification/development? Are there design docs/discussion for all the various choices made?
2. Code review practices? Seems like there hasn't been code review on the smattering of merge requests I looked at here? https://cue-review.googlesource.com/q/status:merged
3. Is a comparison to other config languages available somewhere? (jsonnet, nix, dhall, GCL, ...)
4. Are there any teams already extensively using Cue (beyond experimentation)?
5. What's the roadmap/timeline?

Thanks so much!

[wstrange]

See #33 for an indepth comparison of Jsonnet and Cue.

[mpvl]

@joshburkart: thanks for your interest!

The project is still early stages, although far less than, say 6 months ago.

Code reviewing is a bit spotty, but at least language design choices are reviewed quite extensively. A lot of the discussions you can find on doc/ref/spec.md, but, granted, a lot of it is also in person. By far most of the APIs I'm adding now are a direct result of concrete uses, however.

There are also internal docs with design choices and discussion that I plan to make external at some point. To that extent, I'm working on setting up a website (with help of @xinau) for documentation.

I am the main developer on the project, but I do have some good input from team mates and others. It is currently my main focus. My main development effort is centered around using CUE for the constraint pipeline in Istio (currently {Proto, Go} -> CUE -> OpenAPI). This seemingly simple application needs access to a lot of the internals of CUE evaluation (intermediate results), so it is has had a good impact and been a good test of code quality.

There are some important additions to the language needed to allow CUE to operate on 100% native APIs, including these of Kubernetes. Most notably closed structs and associative lists. My aim is to have those ready by mid September (design is in an advanced stage and I have some working implementation), but I don't want to rush language changes as they tend to be kind of permanent.

Note that I'm the original co-author of GCL and want CUE to incorporate the lessons learned and avoid including the bad parts of GCL. :) But note that CUE takes a very different approach from the GCL/Jsonnet class of languages, etc. See #33, the issue @wstrange referenced, for details.

[joshburkart]

@mpvl Thank you so much for the detailed and thoughtful response! I'm officially a fan of the project and look forward to experimenting more.

[cueckoo]

This issue has been migrated to cue-lang/cue#71.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.