なんでだろうね。 お前が作るんだよって話もあると思うのだけど、それにしても極端に少ない印象を受けている。
たとえば Go や Python, TypeScript, Rust あたりは、雨後の筍のように HTTP Server を書くためのライブラリが乱立している。それぞれに特徴があって、OpenAPI との接続がいい感じになってたりミドルウェアが揃ってたりする。 このへんの言語はメジャーだから、という話に思えるかもしれないが、新興言語でも昨今は HTTP 関連ライブラリは割と乱立するイメージがある。 たとえば gleam なんかは、 https://github.com/gleam-lang/awesome-gleam?tab=readme-ov-file#http-servers を見るだけでも3つある。（まぁこれはずるいか。CGIも含んでるし、Erlang / JS がバックエンドだから。）
Kotlin にはあまりそういうのはない。HTTP Server を書こうと思ったら、Ktor か Spring という感じ。 そして Ktor にはあまりエコシステムの広がりを感じない。Ktor 公式に Plugins がいろいろ書かれているけど、Go とかと比べるとかなり貧弱な印象。 言語としての利用度合いでいえば、Kotlin もそれなりに人気のはずでは...？
いくつか理由は思いつく。 個人ユースで Kotlin を選ぶ人が少ないので、小粒なライブラリが乱立する環境でない。 Java エコシステムに乗っかれることが Kotlin を使う非常に大きな理由になっているので、逆にいえば Java エコシステムで十分。 とか。 JVM はいまから新規に小粒のアプリケーションを作るときには選択肢にあがりづらいよなと正直思う。 組織的に開発するようなエンプラよりのものでないと、積極的に選び辛い。
Ktor のうえに広がりがないのは、Ktor の独自路線感にも一因がある気がする。 Ktor での概念整理が、一般的な HTTP Server における概念整理と違うというか。 Middleware じゃなくて Plugin ってよぶんだーとか、グローバルなエラーハンドラのことを StatusPage Plugin ってよぶんだーとか。 Hono がでてきたときにドキュメントを読んでいて、概念が基本的にはよくあるやつ（Go とかでもよく見るような）だったので、ザーッと眺めてなるほどねとなれたんだが、Ktor にはそれが通じないんだよな。
ちょっと Ktor の上に Hono や Go の net/http 的な API を生やす wrapper が欲しくなってしまった。 せっかく Kotlin Native や Kotlin JS も頑張っているようなので、もう少し軽量に便利なものを作れる感じになって広まるといいなと思う。 なんか作れるものがないか考えて貢献してみたい気持ちになった。
