4 ms·

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 adop

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.

4ad 3y ago
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.
- the_duke 3y ago
  > Getting feedback from the community about what other languages they'd want supported first Rust and Python would be my top picks.
- baq 3y ago
  C library gets to halfway to everywhere to paraphrase a saying.
  - thayne 3y ago
    Or just a c compatible ABI. The implementation doesn't have to be in C, it could be rust or zig or c++ or nim or ...
- chefandy 3y ago
  Thanks for working on it. Useful stuff.
- lars_francke 3y ago
  Because you asked for this feedback: Rust
- teleforce 3y ago
  Can we have D language support? For those who want the justifications for CUE, this is an excellent write up. [1] How CUE Wins: https://blog.cedriccharly.com/post/20210523-how-cue-wins/ https://blog.cedriccharly.com/post/20210523-how-cue-wins/
- exceptione 3y ago
  .net would benefit from it.
- thayne 3y ago
  I'd like support on the JVM, in addition to rust which was already mentioned in other comments.
kkukshtel 3y ago
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.
- 4ad 3y ago
  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.

4ad 3y ago

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.

the_duke 3y ago
> Getting feedback from the community about what other languages they'd want supported first Rust and Python would be my top picks.
baq 3y ago
C library gets to halfway to everywhere to paraphrase a saying.
- thayne 3y ago
  Or just a c compatible ABI. The implementation doesn't have to be in C, it could be rust or zig or c++ or nim or ...
chefandy 3y ago
Thanks for working on it. Useful stuff.
lars_francke 3y ago
Because you asked for this feedback: Rust
teleforce 3y ago
Can we have D language support? For those who want the justifications for CUE, this is an excellent write up. [1] How CUE Wins: https://blog.cedriccharly.com/post/20210523-how-cue-wins/ https://blog.cedriccharly.com/post/20210523-how-cue-wins/
exceptione 3y ago
.net would benefit from it.
thayne 3y ago
I'd like support on the JVM, in addition to rust which was already mentioned in other comments.

kkukshtel 3y ago

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.

4ad 3y ago
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.