yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。

しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。

例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない（複数の経路から同じノードに到達できる）ということがある。本質的にはグラフになっている。

一方、kubernetesなどを見てもそんなことは全く考えられていない。全てのキーは単に文字列しか考えられていないし、エイリアスがレスポンスに出てくることはあり得ない。入力にエイリアスがあった場合の処理は自分はやったことがないのでわからないけど可能なら単にコピーしていたりするだけで、循環はスキーマに合致せずにエラーを返して終わりだろう。実際のところ、kubernetesのAPIサーバはyamlもjsonも返せるようになっているので、jsonで表現できないデータ表現はkubernetesにはあり得ない。

要するにyamlである必然性は全くない。単純に、jsonみたいだがもう少し「簡単に」かけてコメントのある何かというのが望まれていて、標準的だったのがyamlだったというのが本当のところだろうと思う。

ただ本当にこれが望まれているものだったのか、というのは謎でもある。yamlは文字列も数字もクオートなしで書けるのでちょっとした変更でデータ型が意図せず変わってスキーマに一致しなくなったりとか、インデントに意味があるのでうっかりミスでおかしくなったりとか、全体的に非常にerror proneなところが大きい。やりたいことは「なんか少しだけオシャレなJSON」なのにオーバースペックすぎる。なんというか、vscodeの設定ファイルみたいな、JSONにコメントを書けるようにすると言った拡張だけするのが望まれていたんじゃないか、という気もする。

kubernetesを出すときか、別のタイミングがあり得たのか知らないけれど、何か別のフォーマット、jsonnetとかcueとかdhallとかHCLとか……なんかそういうものを作ってそれを使えるようにしておけばよかったんじゃないか、という気がしないでもない。社内のborgは独自の設定ファイルだったからyamlにする必要はなかっただろうにね。

もっとも、新しくオープンソースプロジェクトを立ち上げるにあたって設定言語を独自に策定、というのはやりたくなかったのだろうね。yamlがここまで使われているのには「それが標準規格のものだから」というのはある気がする。コメント付きのJSONを処理するためのパーサというのはどのプログラミング言語にもあるわけではないけど、標準規格のフォーマットは大体パーサライブラリがあるので。

ただいかにもstatus quoであってこれをなんとか打開することがあったりしないんだろうか……といつも思っている。そう思ってる人がいるから、結構いろんな設定言語が色々あるんだろうけども。

（Helmについても色々思うところがあるが今回はオフトピックなので次回に持ち越します）

• Uncategorized