Pkl - Appleが作った設定向けプログラミング言語

• Pkl（「Pickle」と発音）は、設定を生成するためのプログラミング言語で、Appleが社内で使用していたものをオープンソース化し、初のリリースを発表

  • "Configuration that is Programmable, Scalable, and Safe"

• JSON、YAML、Property Listsのような静的言語には、複雑さが増すと限界がある
• Pklは、静的言語と汎用プログラミング言語の間の調和を目指している

Pkl クイックツアー

• 開発者に親しみやすい文法と学びやすさのために、クラス、関数、ループ、型注釈などの機能を含む
• Pklファイルは設定スキーマを定義し、ほかの設定データを定義するために使われる
• Pklプログラムは、YAML、JSON、XMLなどの一般的な形式に簡単にレンダリングできる

組み込みのバリデーション

• データは有効でなければならず、Pklでは型注釈を使ってバリデーションを実現する。
• 型注釈では制約条件を定義でき、制約に違反すると評価エラーが発生する。

パッケージ共有

• Pklは、パッケージを公開し、プロジェクトで依存関係として取り込める機能を提供する
• GitHub Releasesでパッケージを簡単に作成・公開でき、プロジェクトを通じて依存関係を管理できる

言語バインディング

• Pklはテキスト出力として設定を生成でき、ほかの言語にライブラリとして組み込むこともできる。
• Pklスキーマは対象言語のクラス/構造体として生成でき、Swift、Go、Java、Kotlinなどをサポートする

エディタサポート

• Pklは最高の記述体験を目指している
• IntelliJプラグインを含め、JetBrainsエディタ向けに豊富なサポートを提供する
• 自動補完、ナビゲーション、バリデーションなどの機能を提供し、Language Server Protocolのサポートも計画している

次のステップ

• Pklに関する詳細ガイド、言語リファレンス、GitHub Discussionsを通じたコミュニケーションを案内している
• Pklの使用例のためのサンプルリポジトリ、CLIのダウンロード、エディタプラグインのインストールを勧めている

GN⁺の意見:

• Pklは、設定管理の複雑さを解決するために作られた新しいプログラミング言語であり、開発者にとって有用そうだ。
• 組み込みのバリデーションとパッケージ共有機能は、コードの再利用性と保守性を向上させる可能性がある。
• さまざまな言語へのバインディングとエディタサポートにより、Pklをより多くの開発環境に適用できるようになり、開発者がより簡単に設定管理を行えるようになるだろう。

[secret3056]

もしかしてと思っていたら、Goバインディングがあるんですね。AppleもGoをかなり使っているようです。
apple/pkl-go: Pkl bindings for the Go programming language

[GN⁺]

Hacker Newsの意見

• Hacker Newsコメント要約:
  • 25年前は、ほとんどのプログラムがGUIによる設定機能とヘルプを提供していた。設定はiniファイルやWindowsレジストリに保存され、手動で編集することもできた。現在では、設定ファイルを生成するために87MBのバイナリ形式のプログラミング言語を使わなければならず、この言語自体を実行するためにも設定ファイルを手動で作成する必要がある。このままだと、設定ファイルを生成するプログラミング言語のために500GBのフレームワークが必要になりそうで、現代の開発者は問題を作り出す仕事をしているように見える。
  • PklはAppleで社内利用されていた最高のツールの1つであり、今回オープンソース化されてうれしい。あるチームは数千行規模のk8s設定をpklへ無事に移行し、pklを使って2つの監視ツール向けの設定、静的ドキュメントサイト、さらにそれらをつなぐアラート定義まで作成した。このツールを勧めたいし、また使えるようになって興奮している。
  • PklはGraalVM Truffleフレームワークを使って構築されており、Futamura射影を用いたランタイムコンパイルをサポートしている。Appleと長い間この作業を進めてきたが、ついにソースコードを見られるようになってとてもうれしい。（GraalVM開発者のコメント）
  • HTTPリソースを取得したりファイルシステムからファイルを読んだりできる機能や、チューリング完全性は、設定言語としては予想外の機能だ。この複雑さが正当化されるのか気になる。
  • 文書を少し読んだ限りでは、スキーマ定義と言語を最小値の受け渡し手段にするという発想にあまりにも傾倒しているように見える。過度な利用によって予期しない失敗モードが生まれるのではないかと懸念している。ただし、これこそが中核機能なのかもしれない。つまり、pklをソフトウェアに追加する人は皆、最終的に生み出される設定モンスターの形成に参加することになる。構造のない混沌より、統一されたシステムのほうがまだましだという前提に立っている。
  • IntelliJ、Visual Studio Code、Neovim向けのプラグインや拡張機能が提供されており、近いうちにLanguage Server Protocol対応も追加される予定だ。なぜ最初にLSPを実装しなかったのか、あるいはそれだけを実装しなかったのか理解できない。すべてのエディタがLSPを内蔵サポートしているので、個別実装は不要だったはずだ。
  • 設定言語について長いこと考え、スキーマとの愛憎関係も経験した結果、設定にリッチな型は不要だという結論に至った。静的型付けのプログラミング言語を使い、設定言語側では文字列、配列、ハッシュマップだけを型として使い、すべての型検証はパース段階に押し込みたい。
  • Cueに似ているが、より原始的で、原則性が弱く、Javaで書かれている。
  • Pklが解決しようとしている問題を理解するのに苦労している。タイトルを読んだときは、PklはTOMLのような新しくてより良い設定言語なのだと思ったが、記事を読むと、Pklは設定を_生成_するための言語だという印象を受けた。Pklは設定ファイルそのものではなく、設定をより標準化された方法で構築し再利用するのに役立つ抽象化ツールのように見える。たとえば複数のプロジェクトで共有したり繰り返し使ったりしたいTerraformやCloudformationの設定がある場合、最も簡単な方法は別のプロジェクトからコピー＆ペーストして、数行だけ変更してそのプロジェクト向けに調整することだ。Pklはこうした問題の解決に役立つのか、それとも何か別の点を見落としているのか気になる。