RFC: Optional Alternative Configuration Languages in Atmos

# Describe the Feature

Over the years, one of the most surprisingly popular features of Atmos has been templating. What originally started as a small escape hatch — mainly for variable interpolation — has grown into one of the most used (and, honestly, over-used) parts of Atmos.

Speaking personally: I’ve never been a big fan of heavy YAML templating. It’s fragile, hard to validate, and easy to misuse. The multi-phase nature of “render text → then parse YAML” introduces problems that are fundamentally hard to solve:

- validation becomes nearly impossible,
- users can accidentally generate invalid YAML,
- debugging becomes harder,
- the configuration model becomes ambiguous and brittle.

Helm charts suffer from the same issues — it works until it really doesn’t.

Atmos has historically been firm about using YAML for configuration.

But maybe it’s time to acknowledge a simple truth:

The YAML escape hatch has outgrown its original purpose.

It’s become both powerful and problematic.

# Proposal

What if Atmos supported alternative syntax for configuration like HCL, Pkl, Starlark, etc.

## 1. HCL (Terraform Syntax)

Familiar to the community and well-suited to structured configuration.

Pros:

- strong types
- expressive but predictable
- great validation
- good ecosystem support

Would an HCL-powered Atmos config be useful?

2. Pkl (Pickle)

A modern configuration language built specifically for typed, validated configuration.

Pros:
- excellent validation
- strict types
- imports/modules
- no templating hacks
- great tooling

Would you adopt Pkl-based stacks?

3. TypeScript

A popular choice when teams want flexibility, IDE support, and strong type tooling.

Pros:
- rich language
- massive ecosystem
- autocomplete, intellisense, real-time validation
- easy for frontend/backend engineers

Concerns:

too much power?
configuration becoming “code”?

Still, many tools (Next.js, Expo, ESLint, etc.) have moved toward TS configs successfully.

Would a TypeScript-based Atmos DSL feel natural?

4. Starlark

Deterministic, Python-inspired, and widely used in Bazel.

Pros:
- predictable
- simple syntax
- safe language
- good middle ground

Would Starlark satisfy your needs?

# Why We're Asking

Templating gave users a dynamic escape hatch.

But over time, that escape hatch has become:

- a source of invalid YAML
- hard-to-trace bugs
- a multi-phase evaluation model
- something that undermines validation & correctness
- a de facto programming language inside YAML

Atmos has matured. Its users have matured. And maybe our configuration model should mature too.

But we don’t want to remove the current model or force changes.

We want to offer better, safer alternatives, with a smoother path for teams that want more structure.

## Questions for the Community

- Do you feel the same friction with YAML templating?
- Are you interested in optional, alternative configuration languages?
- If we supported multiple syntax backends, which would you prefer?
- HCL
- Pkl
- TypeScript
- Starlark
- Other?
-
- Would you adopt them incrementally in your stacks?

Your insights will help shape the future design of Atmos configuration.

Thanks for being part of this journey!

No files, tests, or entry points are named in this RFC. Start by reviewing the community discussion around HCL, Pkl, TypeScript, and Starlark, then define the preferred configuration language and scope. Done would require an agreed design and implementation plan rather than a single isolated change.

Written by the indexing model from the issue text.