10 ms·

So like cue [0] but more primitive, less principled and in java? [0] https://cuelang.org https://cuelang.org

leblancfg 3y ago
That’s what I’m seeing as well. Curious to try it out to see how its expressiveness compares to Cue. Looks like it’s Turing-complete as opposed to Cue, which is a plus… but that comes with downsides. One thing I like to see is the direction of “declare types and validations in a single place, integrate with any language”. My daily codebase atm has types declarations in typescript, cue, pydantic and for our database… and it’s driving me bonkers seeing as most types are already declared in Cue to start with. I played a little with packages meant to translate them i.e. Cue -> TS, but nothing worth the effort. IMO it would be a big upside for Cue to handle these as first class language features.
- ratorx 3y ago
  What advantages does Turing-completeness provide for a configuration language?
  - neongreen 3y ago
    There are three (maybe more?) ways things can be Turing-incomplete: 1. You are limited to N evaluation/reduction steps. 2. The language doesn't include primitives like recursion or loops. 3. You can have recursion or loops, but the language makes you somehow prove that your program will terminate. I think (1) would be fine, but I don't know any configuration languages that use this approach. (2) is restrictive/annoying whenever you want to implement any logic in the config language library. Eg. a tool uses a homegrown data format BAML and you need to convert JSON to BAML in the config. Now either you have to write and manually call a preprocessor, or you need to use a patched version of the <config language evaluator> that will have JSON->BAML as a built-in, or you must implement JSON->BAML without loops or recursion. For a more realistic example, imagine that a certain config string has to be HTML-escaped and the config language doesn't provide a built-in for that purpose. (3) -- you don't want it. There are languages (like Agda) that let you prove things like "this program terminates", but writing those proofs can be harder than writing the program itself.
    - ratorx 3y ago
      I think 2) seems incorrect. What you can’t have is unbounded loops and recursion. Bounded loops are perfectly fine and I don’t tend to need unbounded ones when programming (with exceptions being infinite loops for handling asynchronous events, which a configuration language doesn’t need to do). Recursion is trickier. I think banning it or simply limiting stack depth seems fairly reasonable? In fact I’m pretty sure most Turing-complete languages have a stack depth limit, so unbounded recursion is not allowed for those either. I don’t see a limit being a problem, because again this is a config language. I don’t see why HTML escaping needs Turing-completeness. It shouldn’t need any unbounded iteration (it should be limited to the size of the input string) or unbounded loops. In general, I can’t think of any typical data processing code where turning completeness is required, but could be wrong. Do you have any practical examples of transformations that need unbounded iteration?
      - neongreen 3y ago
        > I don’t see why HTML escaping needs Turing-completeness. First of all, let's avoid "Turing-completeness" because then we might start arguing about whether a language with unrestricted recursion is or isn't Turing-complete since there are stack depth limits / memory limits / universe will end one day / etc. I would phrase this question as "why would HTML escaping need unrestricted recursion or loops" -- since in practice config languages either have unrestricted recursion or loops (Nickel), or they don't (CUE, Dhall, Starlark). For HTML escaping specifically, just having `.map(f)` and `.concat` available (in functional languages), or `for char in string` (in imperative languages), would be enough. For something like HTML un-escaping, it's already trickier. If you are using recursion, your language needs to understand the concept of the string becoming "smaller" at each step. If you are using loops, `for ... in ...` is not enough anymore. An even trickier example would be mergesort: merge(xs, ys) = ... mergeSort(xs) = let len = xs.length left = mergeSort(xs.slice(0, len/2)) right = mergeSort(xs.slice(len/2, len)) in merge(left, right) It might seem obvious that this should terminate, because of course `.slice` will return a smaller array, but the actual termination proof in Agda is already something I wouldn't want in my config language: <https://stackoverflow.com/a/22271690/615030 https://stackoverflow.com/a/22271690/615030> (Not to mention that this implementation is faulty and will loop at len=1.) Limiting stack depth at [arbitrary number] -- this is similar to (1). I don't know why configuration languages don't do it, to be honest.
  - leblancfg 3y ago
    Many data transformations that you take for granted in other languages are either impossible or require amazing feats of contortion of the language to make happen.
- mirekrusin 3y ago
  Javascript/typescript don't have introspection or any autogen between static and runtime types either. Cue is not general purpose language, with emphasis on it - because it's a good thing. Asking for upstream embedded support feels like asking for bash interpreter, why would you need it in the first place? It's based on completely different, logic based paradigms, use it as it is meant to be used - as top level configuration aiding language. Declare policies and generation in it and interface with other languages/tooling though input/output json/yml.
gregwebs 3y ago
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
IshKebab 3y ago
Looks like it might fix three big issues I had with Cue: 1. The only way to use it is to run their Go CLI app to convert the Cue into JSON and then load that. That sucks. I want native support. Jsonnet does this a lot better (https://jsonnet.org/ref/bindings.html https://jsonnet.org/ref/bindings.html), and PKL at least supports 4 languages. Cue only supports Go directly. Not good. 2. Cue has a super fancy type system, but as far as I could figure out there's no way to actually take advantage of this in an IDE, which is like 60% of the benefits of fancy type systems. In a Cue document you can't say "this is the schema". XML had that decades ago (and it has awesome IDE integration with Red Hat's XML extension for VSCode). Even JSON can sort of do it via `$schema`. The docs are a bit scant but it looks like this supports it too. The fact that Cue doesn't sucks. 3. Cue is pretty much only a fancy type system. It's a really elegant and nice type system, but that's it. It doesn't even have functions. So it isn't going to help with a lot of the things that Jsonnet and PKL help with. This is not really in the same area as Cue. It's a way more direct competitor to Jsonnet and looks better, based on my brief skim. My only concern with these sorts of things is that they're basically a whole new programming language, but without many of the features you'd want from a real programming language. It's in an uncanny valley. Does look nice though.
- bbkane 3y ago
  Love this comment and I agree with basically everything. What are you using for configuration these days? I've fallen back to YAML because at least its already used for a lot of tools, and has comments, jsonschema support in VSCode giving IDE features, language library support, yamllint, and yq for formatting/querying/mass-updating from the CLI
  - IshKebab 3y ago
    Yeah I actually haven't found a great answer yet. Here's everything I've tried and why it sucks: * JSON. No comments. Deal-breaker * JSONC. No unique file extension so its difficult to distinguish from JSON. Poor library support due to library authors drinking the "comments are bad" koolaid. * JSON5. This would be an excellent option IMO except that library and IDE support is not great. * JSON6. This just complicates JSON5 for minimal benefits. Pointless. * Cue. As described. * Jsonnet. Pretty good option tbh! However I couldn't get the Rust library to work. It's a low level parser, seems like you can't just plug it into Serde, which is what 99% of people really want. Also I ran into the "uncanny valley" effect where you can do some things but not all. So it tricks you into writing some programmatic config (e.g. with string manipulation) but then you find you can't do that string manipulation. * Dhall. Weird syntax (backslash to declare functions. I've also heard it is slow. Didn't try this too much. * YAML. Obviously YAML is the worst option. However I did realise you can use it as basically JSON5 except with a different comment character, which is not too bad. * Starlark. Actually I haven't tried this yet but it looks promising. So yeah I have no idea at the moment. I wonder if it would be worth defining a "YAML JSON5" format, that's basically YAML-compatible JSON5.
cqqxo4zV46cp 3y ago
Yes. I am sure it’s that simple. I’m sure that there are all downsides and no upsides. This is the first time in history where one technology is a strict superset of a competing technology, from all perspectives. /s I really don’t know why this snark is necessary.
- mirekrusin 3y ago
  Primitive and less principled doesn't imply "downsides". Go is more primitive and less principled than Haskell, yet it's useful and oftentimes better due to its primitiveness. Cue is written in Go for example.
aeontech 3y ago
I think everyone appreciates links to similar projects for comparison, but a more in-depth comment would probably come across better - the "less principled and more primitive" sounds like a thoughtless off the cuff ad hominem dismissal. Consider that some engineers poured a lot of heart into what they were building, and are probably excited to finally share it with the world. I am not saying you have to love it, but just brutally putting it down with no justification seems really rough. Snark is easy.
runeks 3y ago
I wish the Cue docs were better. I arrived here https://cuelang.org/docs/usecases/configuration/ https://cuelang.org/docs/usecases/configuration/ but it doesn’t answer basic questions like “can I define my own validation functions (the > < != operators used in the example)?”.

That’s what I’m seeing as well. Curious to try it out to see how its expressiveness compares to Cue. Looks like it’s Turing-complete as opposed to Cue, which is a plus… but that comes with downsides. One thing I like to see is the direction of “declare types and validations in a single place, integrate with any language”. My daily codebase atm has types declarations in typescript, cue, pydantic and for our database… and it’s driving me bonkers seeing as most types are already declared in Cue to start with. I played a little with packages meant to translate them i.e. Cue -> TS, but nothing worth the effort. IMO it would be a big upside for Cue to handle these as first class language features.

ratorx 3y ago
What advantages does Turing-completeness provide for a configuration language?
- neongreen 3y ago
  There are three (maybe more?) ways things can be Turing-incomplete: 1. You are limited to N evaluation/reduction steps. 2. The language doesn't include primitives like recursion or loops. 3. You can have recursion or loops, but the language makes you somehow prove that your program will terminate. I think (1) would be fine, but I don't know any configuration languages that use this approach. (2) is restrictive/annoying whenever you want to implement any logic in the config language library. Eg. a tool uses a homegrown data format BAML and you need to convert JSON to BAML in the config. Now either you have to write and manually call a preprocessor, or you need to use a patched version of the <config language evaluator> that will have JSON->BAML as a built-in, or you must implement JSON->BAML without loops or recursion. For a more realistic example, imagine that a certain config string has to be HTML-escaped and the config language doesn't provide a built-in for that purpose. (3) -- you don't want it. There are languages (like Agda) that let you prove things like "this program terminates", but writing those proofs can be harder than writing the program itself.
  - ratorx 3y ago
    I think 2) seems incorrect. What you can’t have is unbounded loops and recursion. Bounded loops are perfectly fine and I don’t tend to need unbounded ones when programming (with exceptions being infinite loops for handling asynchronous events, which a configuration language doesn’t need to do). Recursion is trickier. I think banning it or simply limiting stack depth seems fairly reasonable? In fact I’m pretty sure most Turing-complete languages have a stack depth limit, so unbounded recursion is not allowed for those either. I don’t see a limit being a problem, because again this is a config language. I don’t see why HTML escaping needs Turing-completeness. It shouldn’t need any unbounded iteration (it should be limited to the size of the input string) or unbounded loops. In general, I can’t think of any typical data processing code where turning completeness is required, but could be wrong. Do you have any practical examples of transformations that need unbounded iteration?
    - neongreen 3y ago
      > I don’t see why HTML escaping needs Turing-completeness. First of all, let's avoid "Turing-completeness" because then we might start arguing about whether a language with unrestricted recursion is or isn't Turing-complete since there are stack depth limits / memory limits / universe will end one day / etc. I would phrase this question as "why would HTML escaping need unrestricted recursion or loops" -- since in practice config languages either have unrestricted recursion or loops (Nickel), or they don't (CUE, Dhall, Starlark). For HTML escaping specifically, just having `.map(f)` and `.concat` available (in functional languages), or `for char in string` (in imperative languages), would be enough. For something like HTML un-escaping, it's already trickier. If you are using recursion, your language needs to understand the concept of the string becoming "smaller" at each step. If you are using loops, `for ... in ...` is not enough anymore. An even trickier example would be mergesort: merge(xs, ys) = ... mergeSort(xs) = let len = xs.length left = mergeSort(xs.slice(0, len/2)) right = mergeSort(xs.slice(len/2, len)) in merge(left, right) It might seem obvious that this should terminate, because of course `.slice` will return a smaller array, but the actual termination proof in Agda is already something I wouldn't want in my config language: <https://stackoverflow.com/a/22271690/615030 https://stackoverflow.com/a/22271690/615030> (Not to mention that this implementation is faulty and will loop at len=1.) Limiting stack depth at [arbitrary number] -- this is similar to (1). I don't know why configuration languages don't do it, to be honest.
- leblancfg 3y ago
  Many data transformations that you take for granted in other languages are either impossible or require amazing feats of contortion of the language to make happen.
mirekrusin 3y ago
Javascript/typescript don't have introspection or any autogen between static and runtime types either. Cue is not general purpose language, with emphasis on it - because it's a good thing. Asking for upstream embedded support feels like asking for bash interpreter, why would you need it in the first place? It's based on completely different, logic based paradigms, use it as it is meant to be used - as top level configuration aiding language. Declare policies and generation in it and interface with other languages/tooling though input/output json/yml.

gregwebs 3y ago

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

IshKebab 3y ago

Looks like it might fix three big issues I had with Cue: 1. The only way to use it is to run their Go CLI app to convert the Cue into JSON and then load that. That sucks. I want native support. Jsonnet does this a lot better (https://jsonnet.org/ref/bindings.html https://jsonnet.org/ref/bindings.html), and PKL at least supports 4 languages. Cue only supports Go directly. Not good. 2. Cue has a super fancy type system, but as far as I could figure out there's no way to actually take advantage of this in an IDE, which is like 60% of the benefits of fancy type systems. In a Cue document you can't say "this is the schema". XML had that decades ago (and it has awesome IDE integration with Red Hat's XML extension for VSCode). Even JSON can sort of do it via `$schema`. The docs are a bit scant but it looks like this supports it too. The fact that Cue doesn't sucks. 3. Cue is pretty much only a fancy type system. It's a really elegant and nice type system, but that's it. It doesn't even have functions. So it isn't going to help with a lot of the things that Jsonnet and PKL help with. This is not really in the same area as Cue. It's a way more direct competitor to Jsonnet and looks better, based on my brief skim. My only concern with these sorts of things is that they're basically a whole new programming language, but without many of the features you'd want from a real programming language. It's in an uncanny valley. Does look nice though.

bbkane 3y ago
Love this comment and I agree with basically everything. What are you using for configuration these days? I've fallen back to YAML because at least its already used for a lot of tools, and has comments, jsonschema support in VSCode giving IDE features, language library support, yamllint, and yq for formatting/querying/mass-updating from the CLI
- IshKebab 3y ago
  Yeah I actually haven't found a great answer yet. Here's everything I've tried and why it sucks: * JSON. No comments. Deal-breaker * JSONC. No unique file extension so its difficult to distinguish from JSON. Poor library support due to library authors drinking the "comments are bad" koolaid. * JSON5. This would be an excellent option IMO except that library and IDE support is not great. * JSON6. This just complicates JSON5 for minimal benefits. Pointless. * Cue. As described. * Jsonnet. Pretty good option tbh! However I couldn't get the Rust library to work. It's a low level parser, seems like you can't just plug it into Serde, which is what 99% of people really want. Also I ran into the "uncanny valley" effect where you can do some things but not all. So it tricks you into writing some programmatic config (e.g. with string manipulation) but then you find you can't do that string manipulation. * Dhall. Weird syntax (backslash to declare functions. I've also heard it is slow. Didn't try this too much. * YAML. Obviously YAML is the worst option. However I did realise you can use it as basically JSON5 except with a different comment character, which is not too bad. * Starlark. Actually I haven't tried this yet but it looks promising. So yeah I have no idea at the moment. I wonder if it would be worth defining a "YAML JSON5" format, that's basically YAML-compatible JSON5.

cqqxo4zV46cp 3y ago

Yes. I am sure it’s that simple. I’m sure that there are all downsides and no upsides. This is the first time in history where one technology is a strict superset of a competing technology, from all perspectives. /s I really don’t know why this snark is necessary.

mirekrusin 3y ago
Primitive and less principled doesn't imply "downsides". Go is more primitive and less principled than Haskell, yet it's useful and oftentimes better due to its primitiveness. Cue is written in Go for example.

aeontech 3y ago

I think everyone appreciates links to similar projects for comparison, but a more in-depth comment would probably come across better - the "less principled and more primitive" sounds like a thoughtless off the cuff ad hominem dismissal. Consider that some engineers poured a lot of heart into what they were building, and are probably excited to finally share it with the world. I am not saying you have to love it, but just brutally putting it down with no justification seems really rough. Snark is easy.

runeks 3y ago

I wish the Cue docs were better. I arrived here https://cuelang.org/docs/usecases/configuration/ https://cuelang.org/docs/usecases/configuration/ but it doesn’t answer basic questions like “can I define my own validation functions (the > < != operators used in the example)?”.