4 ms·

Looks like it has better IDE integration. Still, I am going to stick with cue because of what you mentioned and also because it is a community project. Apple ha

Looks like it has better IDE integration. Still, I am going to stick with cue because of what you mentioned and also because it is a community project. Apple has very few actively maintained open source projects and sometimes such projects are difficult to contribute to or have wavering support for the open source side. It is great having corporate backing behind something like swift that needs a massive amount of work, but for cue, I am happy with steady improvements meeting the needs of a wide community once I can figure out a good IDE integration.

4ad 3y ago
FWIW, we (CUE) are currently working on a LSP for CUE which should improve the IDE experience.
- 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

4ad 3y ago

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

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