Pros of Skylark

• More actively maintained with recent updates and contributions
• Includes additional tools and utilities for working with Starlark
• Better documentation and examples for users

Cons of Skylark

• Less integrated with the Bazel ecosystem
• Smaller community and fewer contributors
• May have compatibility issues with some Bazel-specific features

Code Comparison

Skylark:

def my_rule_impl(ctx):
    output = ctx.actions.declare_file(ctx.label.name + ".out")
    ctx.actions.run_shell(
        outputs=[output],
        command="echo 'Hello, Skylark!' > {}".format(output.path),
    )
    return [DefaultInfo(files=depset([output]))]

Starlark:

def my_rule_impl(ctx):
    output = ctx.actions.declare_file(ctx.label.name + ".out")
    ctx.actions.run_shell(
        outputs=[output],
        command="echo 'Hello, Starlark!' > {}".format(output.path),
    )
    return [DefaultInfo(files=depset([output]))]

The code comparison shows that both implementations are nearly identical, with the main difference being the project name in the output message.

Pros of go-jsonnet

• Designed specifically for configuration management and data templating
• Supports advanced features like import statements and library functions
• Offers a more expressive and flexible syntax for complex data structures

Cons of go-jsonnet

• Less integrated with build systems compared to Starlark
• May have a steeper learning curve for users unfamiliar with JSON-based languages
• Limited use cases outside of configuration management

Code Comparison

Starlark:

def greet(name):
    return "Hello, " + name + "!"

result = greet("World")
print(result)

go-jsonnet:

local greet(name) = "Hello, " + name + "!";

{
  result: greet("World")
}

Summary

While Starlark is primarily designed for build system configuration and scripting, go-jsonnet focuses on data templating and configuration management. Starlark offers tighter integration with build tools like Bazel, while go-jsonnet provides more flexibility for complex data structures and configuration scenarios. The choice between the two depends on the specific use case and the ecosystem in which they'll be used.

Pros of HCL

• More flexible syntax, allowing for both configuration and data representation
• Native support for JSON-like structures and heredocs
• Designed for human-readability and ease of use in configuration files

Cons of HCL

• Less focused on programming language features compared to Starlark
• May be less suitable for complex scripting or programming tasks
• Limited built-in functions and standard library compared to Starlark

Code Comparison

HCL:

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  tags = {
    Name = "ExampleInstance"
  }
}

Starlark:

def create_instance(ami, instance_type, name):
    return {
        "ami": ami,
        "instance_type": instance_type,
        "tags": {"Name": name},
    }

example = create_instance("ami-0c55b159cbfafe1f0", "t2.micro", "ExampleInstance")

The HCL example shows its declarative nature and built-in support for resource definitions, while the Starlark example demonstrates its more programmatic approach with functions and variable assignments.

Pros of dhall-lang

• Strong type system with support for dependent types, offering more advanced type-checking capabilities
• Built-in support for importing and referencing external files, enhancing modularity
• Language-agnostic design, allowing for broader application across different programming ecosystems

Cons of dhall-lang

• Steeper learning curve due to its more complex type system and functional programming concepts
• Smaller community and ecosystem compared to Starlark, potentially leading to fewer resources and tools

Code Comparison

Dhall example:

let Config = { name : Text, age : Natural }
let person = { name = "Alice", age = 30 } : Config
in  person

Starlark example:

def create_person(name, age):
    return {"name": name, "age": age}

person = create_person("Alice", 30)

Both examples create a simple configuration structure, but Dhall's static typing and explicit type declarations contrast with Starlark's more Python-like dynamic approach.

Pros of cel-spec

• Designed specifically for expression evaluation in configuration and policy scenarios
• Supports gradual typing, allowing for more flexible and dynamic expressions
• Includes built-in support for protocol buffers and common data types

Cons of cel-spec

• Less mature and less widely adopted compared to Starlark
• Limited to expression evaluation, not suitable for full scripting capabilities
• Smaller ecosystem and fewer available tools and integrations

Code Comparison

cel-spec:

name.startsWith("foo") && auth.user == "admin" && request.time < now - duration("24h")

Starlark:

def check_condition(name, auth, request, now):
    return (name.startswith("foo") and
            auth.user == "admin" and
            request.time < now - timedelta(hours=24))

Summary

cel-spec is tailored for expression evaluation in configuration and policy contexts, offering gradual typing and built-in support for common data types. However, it has a smaller ecosystem and is less mature than Starlark. Starlark, being a more complete scripting language, offers greater flexibility but may be overkill for simple expression evaluation tasks. The choice between the two depends on the specific use case and requirements of the project.

Pros of Buck

• More comprehensive build system with advanced features like caching and distributed builds
• Supports multiple programming languages and platforms out-of-the-box
• Extensive documentation and active community support

Cons of Buck

• Steeper learning curve due to its complexity
• Heavier resource usage, especially for smaller projects
• Less flexibility in customizing build rules compared to Starlark

Code Comparison

Buck:

android_binary(
    name = "app",
    manifest = "AndroidManifest.xml",
    keystore = ":debug_keystore",
    deps = [
        ":app-lib",
    ],
)

Starlark:

android_binary(
    name = "app",
    manifest = "AndroidManifest.xml",
    keystore = ":debug_keystore",
    deps = [":app-lib"],
)

The syntax for defining build targets is similar between Buck and Starlark, with minor differences in formatting and structure. Both use a declarative approach to specify build configurations, making it relatively easy for developers familiar with one system to understand the other.