Roadmap to share

[roman-mazur]

I've been using CUE since the 0.2.x releases and my team has now quite a big codebase of .cue files.
We find the language and tools very helpful and fun to work with. However, we haven't seen any releases since the 0.4.0 version in July. It raises some anxiety :)

I would appreciate it if project maintainers could share some insights on what are the plans for the project, next goals, or prioritized topics.
Maybe there is something already out there that I missed - I'll appreciate a reference in this case.

[verdverm]

• There was a town hall late last year: https://cuetorials.com/videos/townhalls/
• There is a beta out for 0.4.1
• Some announcements were made on Slack

I would agree there is more radio silence from the core maintainers than I expected. That being said, I personally anticipate CUE to have longevity even if it is not developing as fast as we'd hoped. Many people see the game changing utility and are adopting, some bigger companies too.

[myitcv]

Hi @roman-mazur

I've been using CUE since the 0.2.x releases and my team has now quite a big codebase of .cue files.

Wonderful to hear! We'd be delighted to learn more about how you use CUE, what works well for you, what doesn't work so well, changes/features/improvements you'd like to see etc. I will follow up offline (an offer which is of course extended to others reading this).

It raises some anxiety :) … I would appreciate it if project maintainers could share some insights on what are the plans for the project, next goals, or prioritized topics.

Thank you for raising this, and apologies for the delay in replying. By way of introduction, I am one of the core CUE team members.

As @verdverm pointed out, the town hall back in October last year contains discussion about a number of key points related to your question:

• what we should be solving for in the CUE project;
• the needs of the open source project, and where a foundation fits into that picture;
• the contribution process and how we can grow our contributor base;
• a high level roadmap for the CUE project;
• main open issues;
• how and where documentation needs to be improved;
• major proposals and how they fit into the roadmap.

Under the heading of "roadmap" we further listed the following main points:

• getting to v1 and providing a backwards compatibility guarantee;
• planning and staging breaking changes that get us to v1;
• modules and package management;
• wider support for different encodings (i.e. going beyond JSON, YAML, JSONSchema, Protocol Buffers etc);
• documentation;
• performance;
• error handling;
• developer tools like LSP.

If you haven't yet had a chance to watch the town hall, it provides much more detail on the above points. Indeed if you have any questions as a result, I'd be happy to help answer those here.

As you may have seen, in the last month we released v0.4.1 (after a number of pre-releases) and today announced v0.4.2-rc.1. Marcel is currently finalising a large stack of changes that refactor the way in which comprehensions are implemented. This will in turn enable refactoring of disjunctions, performance improvements, structure sharing and much more.

Also to highlight a tweet we have just shared:

https://twitter.com/cue_lang/status/1488920416152391683

More news to come soon!

[roman-mazur]

Thanks a lot for the response @myitcv.

I will try to share more about our experience with CUE, here are some insights from the top of my mind.

• We use it extensively in order to describe the full cloud infrastructure we have across multiple providers (AWS, OpenStack) by defining some higher-level abstractions of terraform resources.
• We ended up using a pattern very similar to "Functions" Some quick example:

#EcsService: {
  // Higher-level parameters.
  serviceName: string
  port: uint

  // Terraform resources.
  tf: {
    resources: aws_ecs_service: "\(serviceName)": { 
      name: serviceName
      ... 
    }
    // Here we can cover ECS task definitions, cloud watch groups, integration with our metrics collection, etc.
  }
}

// And then we can use it like.

allResources: {
  (#EcsService & { serviceName: "my-test-service"; port: 15000 }).tf
}

Essentially, we implement terraform modules in a different (and in my opinion much more flexible) way.

• One thing that keeps bothering me is referring to the attributes from the outer scope. Note how serviceName is used at the higher level. If we named it name instead, we would get

#EcsService: {
  name: string
  
  let serviceName = name
  tf: resources: aws_ecs_service: "\(name)": {
    name: serviceName
    // ...
  }
}

And so far I haven't been able to find a more elegant alternative.

• Our commands defined in _tool.cue perform an export of terraform definitions into JSON and then call terraform plan and terraform apply.

• With CUE, it becomes very easy to combine definitions from different worlds. For example, we have some experiments with taking the Swagger or OpenAPI specs and using them to define resources for the AWS API Gateway.

• Another idea/experiment we play with is having our "back-of-envelope" calculations in the infra definitions. With CUE, we can define something like the expected usage model, for example:

UsageModel: {
  expectedNumberOfUsers: 100
 
  requirements: {
    diskSpace: expectedNumberOfUsers * 42
  } 
}

And then we can plug UsageModel.requirements.diskSpace into the OpenStack block storage volume definition or set constraints for volume size.

[bttk]

To make it simpler to refer to function arguments in an outer scope, one option is to group them in a struct:

#EcsService: {
  param: {
    name: string
    port: uint
  }
  
  tf: resources: aws_ecs_service: "\(param.name)": {
    name: param.name
    // ...
  }
}

Or alias the function struct itself:

#EcsService: this={
  name: string
  port: uint
  
  tf: resources: aws_ecs_service: "\(this.name)": {
    name: this.name
    // ...
  }
}