I really like CUE, but for most use cases I have I would want to embed it in an application, and Go is the only language with support.
For it to gain more adoption it really needs a rewrite in a low-level language (C/Rust), so it can be exposed in various languages through an extension/FFI.
Making CUE available as a library for other languages is one of our top priorities. Sadly, I can't provide an ETA at this time, all I can say is that I am personally working on this.
Getting feedback from the community about what other languages they'd want supported first would be of massive help, however.
This is honestly my only complaint about Cue after having it used it for a few weeks after looking at everything else in the space (KCL, Jsonnet, Dhall, etc.). Cue is incredible imo and the commenter above talking about not being able to define the schema vs. the data is sort of missing the point - Cue makes them the same thing in a way that really understands the whole role of config langauges and IMO is way better for it. When you start to really understand what a config language _should_ do, Cue is the only option, and most attempts to dismiss it seem like hand-waves in order to push some other preference.
However it only being in Go and not implemented with some C ABI is a major downside for adoption, especially when their documentation itself for implementing the core CLI functionality in a go program (to then compile to a DLL for use in non-Go land) is pretty sparse.
Thank you for your comment. We're working hard to add support for other languages. I agree that exposing a Go library as a C shared object is non-trivial and rough around the edges. We are committed to polishing these edges.
I've been somewhat surprised that CUE bills itself as "tooling friendly" and doesn't yet have a language server- the number one bit of tooling most devs use for a particular language.
Tooling friendly can mean different things to different people. Similarly, different groups of people have different priorities.
It has always been clear that LSP was high priority, but we have many other high priority work that also needs to be done. Most of the work that we do is driven by feedback and demand from the community.
Additionally, we want to do the LSP right instead of quickly hacking something together. That requires more work than one might think.
While CUE has not reached 1.0 yet, people definitely use CUE in production and we work hard not to break any of their code. I can assure you LSP is missing simply because we had other things to tackle first and not because the language is unstable in a colloquial sense.
