Apple Pkl: A Configuration Language to Replace JSON and YAML

Pkl (pronounced “Pickle”) is Apple’s take on configuration-as-code. It sits between traditional formats like JSON and full programming languages like Python, aiming to make configuration more reliable and maintainable.

Here’s what caught my attention about Pkl - it’s not trying to be another general-purpose programming language. Instead, it’s laser-focused on solving one specific problem: making configuration less painful.

As someone who’s wrestled with YAML indentation and JSON’s lack of comments more times than I care to count, I’m intrigued by what Apple is bringing to the table with Pkl.

What Makes Pkl Different?

Configuration files often start simple but grow complex over time. Think about a typical deployment config - it might begin with a few environment variables but evolve into hundreds of lines spanning multiple services. YAML and JSON struggle with this complexity, while general programming languages can be overkill.

Pkl isn’t just another configuration format. It’s a blend between a static config format (like JSON/YAML) and a programming language. Think of it as having the simplicity of YAML but with the power to actually do stuff when you need it.

1
// Basic config
2
name = "My Service"
3
port = 8080
4

5
// Template for shared settings
6
baseService {
7
  image = "nginx:1.19"
8
  healthCheck = true
9
}
10

11
// Reuse template for specific services
12
webService = new baseService {
13
  port = 80
14
}
15

16
apiService = new baseService {
17
  port = 3000
18
}

The code above shows Pkl’s hybrid nature. It’s as readable as YAML but supports abstraction and reuse like a programming language.

Pkl enforces immutability - once you define a value, it can’t be changed. This prevents a whole class of configuration errors where values get accidentally modified. The language also includes built-in validation through schemas:

1
class DatabaseConfig {
2
  host: String
3
  port: Int
4

5
  function validate() {
6
    port > 0 && port < 65536
7
  }
8
}

The schema validates your configuration at evaluation time, catching errors before they reach production.

Pkl is designed to fit into existing workflows. It can output to JSON, YAML, XML, and Java Properties files. This means you can use Pkl to generate configuration for tools that expect these formats. It also offers integration libraries for multiple languages:

1. JVM (Java and Kotlin)
2. Swift
3. Go

These libraries let applications directly read and parse Pkl configurations, eliminating the need for intermediate JSON or YAML files.

Consider a common microservices setup. Each service might need similar but slightly different configuration. In YAML, this often leads to copy-pasted blocks with minor changes. Pkl handles this more elegantly through inheritance and composition.

1
// Base application config with shared defaults
2
class AppConfig {
3
  port: Int = 8080
4
  logLevel: String = "INFO"
5
  timeout: Duration = Duration.seconds(30)
6
}
7

8
// Specific service config
9
api = new AppConfig {
10
  port = 3000
11
  timeout = Duration.minutes(2)
12
}

Do We Really Need Another Language?

I have some reservations about Pkl that warrant discussion. First, introducing a new programming language, even a domain-specific one, brings significant overhead. Every new team member needs to learn it. Every toolchain needs to support it. Every CI/CD pipeline needs to handle it. That’s a lot of friction for something as fundamental as configuration.

The JVM integration also gives me pause. While Pkl claims to be lightweight, requiring a JVM runtime for configuration feels heavy-handed. For simple services or containerized environments where every megabyte counts, this could be a deal-breaker.

There’s also the question of Apple’s long-term commitment. Apple has a history of creating and then abandoning developer tools (remember WebObjects?)

While Pkl is open source, its development appears to be primarily driven by Apple. If they lose interest, the community might not be strong enough to maintain it.

The syntax, while clean, introduces yet another way to do things. We already have YAML, TOML, JSON5, and HCL. Each promised to solve configuration problems, yet here we are with another contender. This fragmentation in the configuration space might actually make things worse, not better.

The validation features, while impressive, could also be achieved with JSON Schema or OpenAPI specifications - tools that already have broad industry adoption and support. Is Pkl really solving problems we can’t solve with existing tools?

Looking at Apple’s own ecosystem, it’s interesting that they primarily use Information Property List and JSON for their platforms’ configuration. If Pkl is such a significant improvement, why isn’t it being used more extensively in Apple’s own products?

These concerns don’t invalidate Pkl’s innovations, but they do suggest we should be cautious about adopting it, especially for projects that don’t have Apple’s scale of configuration complexity.

I’m also skeptical about enterprise adoption. Large organizations often have strict requirements about introducing new languages and tools. Convincing security teams to approve a new configuration language - even one from Apple - could be an uphill battle. The risk/reward ratio might not make sense for many businesses, especially when existing solutions, while imperfect, are well understood and have proven security track records.

These aren’t reasons to dismiss Pkl, but they are factors that deserve serious consideration before jumping on board.

The configuration landscape has been stagnant for years, dominated by formats designed decades ago. Pkl represents a fresh approach that acknowledges configuration’s evolution from simple key-value pairs to complex, mission-critical code.

Sources

• https://github.com/apple/pkl
• https://pkl-lang.org/
• https://opensource.apple.com/projects/pkl/
• https://pkl-lang.org/blog/