Clojurians Log v2

BigConfig is a library rather than a CLI; in fact, building the CLI is the user's responsibility. It functions as both a workflow engine and a template engine that can "glue" Pulumi, Terraform, CDK, and Ansible together. What used to be a mess of folders and shell commands for different tools is transformed into a single, cohesive Workflow step. I am currently focusing on Terraform because of its significant market share, but the same integration can be applied to Pulumi for YAML. While it’s becoming common to integrate Pulumi with Temporal for orchestration, BigConfig with Rama achieves the same result. I’ve written a short comparison here: https://bigconfig.it/start-here/scalability/#pulumi

I could be missing something, but what is the incentive for someone to use this over the existing Terraform ecosystem? To be frank, there is a trend of "well-established thing, but implemented in another language", so I'm approaching this with some healthy skepticism.

@brandon268, I have used Gemini to improve my answer. I hope is ok for you. You have made a fair critique. The "X but in Y language" trap is real, but BigConfig isn’t trying to replace Terraform; it’s trying to solve the structural limitations where HCL starts to break down. If Terraform is the engine, HCL is a static blueprint. BigConfig turns that blueprint into a dynamic program. Here is why that matters: 1. Unified Workflow vs. Static Declarations HCL is excellent for static state, but it struggles with complex logic. BigConfig treats infrastructure as a unified workflow engine. Instead of messy handoffs between Terraform, shell scripts, and Ansible, you can define the entire lifecycle in Clojure. It bridges the gap between provisioning a resource and configuring it within a single, cohesive logic flow. 2. "Level 2" Smart Abstractions Standard Terraform modules are often just thin wrappers. BigConfig allows for what AWS CDK calls "L2 Constructs"—Smart Resources that carry their own logic. For example: • Context-Aware Provisioning: Need to automatically populate a company service catalog when a resource is created? • Integrated Observability: Want to automatically inject OpenTelemetry logging every time an infrastructure change occurs? In BigConfig, these aren't post-provisioning "hacks"; they are first-class functions defined within the resource's own lifecycle. 3. Solving the "Boilerplate" Problem One of the primary complaints from Provider developers in Go is the sheer volume of repetitive, ritualistic code required to manage state and schema. By leveraging Clojure’s macro system, we can generate those complex gRPC mappings and state transitions with a fraction of the code. We aren't just changing the language; we’re reducing the surface area for bugs. 4. Developer Agency For engineers who find DSLs restrictive, BigConfig offers the escape hatch of a general-purpose language. You get the power of Clojure’s immutable data manipulation libraries while remaining 100% compatible with the existing Terraform ecosystem. You don't have to leave the neighborhood; you're just upgrading the tools in your shed.

I totally get using a proper programming language over HCL. No doubt that HCL has a lot of limitations when it comes to larger codebases and writing reusable modules. What differentiates this solution from Pulumi (or the now-retired Terraform CDK)?

Hi @alberto.miorin I write a hell lot of terraform in my day to day work. I really want to understand the product deeply. Can we connect over a meeting some day this week?

I am interested in the idea, and would love to know more, I went through the docs too...

I'm developing in the open: https://github.com/amiorin/terraform-provider-bigconfig I've found @ovidiu.stoica1094 fork of pronto and it works for me. I didn't try neither protojure nor grpc-clj. In the screenshot you can see that I can test the provider in the REPL with one keystroke.

Thanks - I'll take a look