Pkl - Apple's Config Language

Last month I spent 4 hours debugging why our staging environment kept crashing. Turns out someone set memory: "2GB" in our YAML config instead of memory: 2048. The pod scheduler silently failed, defaulted to 128MB, and our Java app kept OOMing.

This is the daily reality of config management. JSON breaks when you need comments. YAML breaks when someone uses tabs instead of spaces. XML breaks your will to live.

The Problem

Configuration lives in this hellish middle ground where it's too complex for static files but too simple for a real programming language. You end up with YAML templates full of ${ENVIRONMENT_VAR} substitutions that break in creative ways.

The Kubernetes "no" bug bit us hard - YAML silently converts the string "no" to boolean false, which broke our Norwegian customers' configs. Took three weeks to track down because it only failed for certain countries.

How Pkl Fixes It

Pkl validates everything at build time. Write your config once, generate JSON/YAML for whatever tools you're using:

port: UInt16(this > 1000)  // This actually prevents port 80 mistakes
database: String(!isEmpty)  // No more empty database URLs in prod

It's sandboxed, so config evaluation can't fuck with your filesystem or make network calls.

What This Actually Means

I switched our team's microservice configs from YAML hell to Pkl about 6 months ago. We had 15 different config files across environments, and keeping them in sync was a nightmare. Someone would update the database timeout in prod config but forget staging, then we'd wonder why staging was timing out.

Now we have 4 Pkl files that generate environment-specific JSON. The type checking caught 3 production bugs in the first week - things like port numbers set to strings, missing required fields, that sort of basic shit that YAML just lets slide.

The Java code generation is solid. Instead of parsing Map<String, Object> and hoping the keys exist, you get proper typed classes with autocomplete. Saved probably 10 hours of config debugging last month.

The Downsides

The learning curve exists. It's not bad if you know any programming language, but your ops team who's used to editing YAML directly will need time to adjust.

IDE support is good in IntelliJ, okay in VS Code. Error messages are actually helpful, which surprised me coming from other config languages.

Performance is fine for normal configs but can get slow on massive Kubernetes manifests. Apple's working on it since they probably generate a lot of iPhone configs.

Pkl runs on GraalVM, which means it JIT compiles config evaluation instead of interpreting everything. Makes a difference on large configs - our 500+ line Kubernetes manifest went from 12 seconds to evaluate down to 2 seconds.

Code Generation

The language bindings actually generate typed code instead of making you parse generic JSON.

Java/Kotlin - Generates builder classes with validation. Instead of config.get(\"database.url\") and hoping the key exists, you get config.database().url() with compile-time checking.

Swift - Generates proper Swift structs with optionals and enums. Your config becomes real Swift code instead of [String: Any] dictionaries.

Go - Generates structs with JSON tags. Perfect for microservices where you need typed config that serializes to JSON for containers.

What Actually Matters

Resource Loading - Pull values from environment variables, files, or HTTPS endpoints at evaluation time. No more shell scripting to inject secrets:

database_url = read(\"env:DATABASE_URL\")
ssl_cert = read(\"file:/etc/ssl/cert.pem\") 
api_config = read(\"https://config-service.internal/api.pkl\")

Package System - URI-based dependencies from GitHub or internal registries. The community packages for Kubernetes and Docker Compose save time.

Object Amending - Inheritance for configs. Define base settings and override for different environments. Much cleaner than YAML anchors.

Developer Experience

IDE Support - IntelliJ plugin is excellent with autocomplete and error highlighting. VS Code support via LSP is decent but not as polished.

Build Integration - Gradle plugin integrates config generation into your build. Validation happens at compile time instead of when you deploy. Caught several type errors before they hit staging.

Version Issues

0.25.x crashes with circular imports - upgrade to 0.26+ if you're splitting configs into modules. Hit this during a refactor and spent an hour figuring out why the LSP server kept dying.

macOS M1/M2 performance was garbage before 0.29.1. Large configs took 5+ seconds to evaluate. Much better now but still slower than Intel machines.

Windows PATH problems - The MSI installer doesn't update PATH correctly half the time. Use Chocolatey or manually add the bin directory.

Future Direction

Three releases per year - February, June, October. They're focusing on performance and IDE improvements instead of language changes, which is smart for a config tool that needs stability.