3 ms·

FWIW, we (CUE) are currently working on a LSP for CUE which should improve the IDE experience.

by 4ad 3y ago

bbkane 3y ago
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. I'm assuming it's becaus CUE is still unstable? Anyway, if others are interested in CUE's LSP work, I think https://github.com/cue-lang/cue/issues/142 https://github.com/cue-lang/cue/issues/142 is the issue to subscribe to
- 4ad 3y ago
  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.
the_duke 3y ago
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.

FWIW, we (CUE) are currently working on a LSP for CUE which should improve the IDE experience.

by 4ad 3y ago

FWIW, we (CUE) are currently working on a LSP for CUE which should improve the IDE experience.

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. I'm assuming it's becaus CUE is still unstable? Anyway, if others are interested in CUE's LSP work, I think https://github.com/cue-lang/cue/issues/142 https://github.com/cue-lang/cue/issues/142 is the issue to subscribe to

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

the_duke 3y ago

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.