朗報！ProtobufでLSPが利用可能になりました！

ついにProtobufでLSP（Language Server Protocol）がサポートされました。快適な開発環境の構築にぜひお役立てください。

LLM全盛の今、Bufが提供しているようなProtobufのレジストリやマイクロサービス向けのcodegen SDKって、正直あまり必要ない気がする。Protobufのメリット（ワイヤフォーマットは別として）の多くに疑問を感じ始めてるんだよね。2010年代に流行ったモノレポやその他の手法も、LLMの台頭を考えるとどうなんだろうって思う。昔はバリバリ信奉してたんだけど、自分の根底にあった前提がどんどん崩れていってるよ。

Protobufを使わなくても何も困らないところを見ててくれ。……ほらね！GoogleのサービスでPythonクライアントをgRPCからJSONを使うようにパッチ当てると、むしろ速くなるし信頼性も上がるんだよ。めちゃくちゃ速くなる。ベンチマーク取ってみなよ！ (コード略) 自分にとって、Protobufのようなものが「良い」というのはこういうことなんだよね。定義の管理や配布は面倒だし、本来ビルドが不要な言語にまでビルドステップを追加させられるし、ほとんどの代替手段より遅い。おまけに一般的な処理を人為的に制限してくる。最高だよね！それに実装のコード品質を見てよ！酔っ払ったインターンのチームが書いたみたいだ。スパゲッティコードの塊なのに、わざわざ複雑なマイクロ最適化を詰め込んであって、普通に書くより遅いし、実装をわかりにくくしてるだけ。ゴミみたいなコードだよ。

Protobufの直接の競合じゃないけど、もし構造体のバージョン管理を必要としないゲーム開発分野にいるなら、「schema」という言語がおすすめだよ。C, C++, C#, Golang, Rust, JavaScriptに対応してるしね。 https://github.com/mas-bandwidth/schema

否定的な意見が多いけど、Protobufの利点の一つはprotoファイルを手書きできることで、だからこそLSPがあれば便利になるんだよ。とはいえ、proto自体がリネームのようなLSPでやりたいような一般的な操作を抑制したり禁止したりしてるんだよね。フィールドのリネームは厳禁だし（修正：これについては後述の訂正を見て）、フィールドの順序入れ替えもそう。protoの核となる考え方は、バージョン間で厳密な互換性を保つことだからね。それ自体、移行の際には制限や課題になるんだけど、ほとんどのエコシステムで無視されがちな互換性についての良いプラクティスを強制してくれる面もある。まぁ、構造の再定義やバージョン互換性のチェックをLLMに丸投げしてやらせるのが簡単っていうのも納得だけどね。

依存関係を見てみたんだけど、既存のProtobufパーサーを使ってないから、スクラッチで再実装したみたいだね。既存の実装だとエラー復旧が難しいからかな？今は詳しく調べる体力がないけど。LSPを実装するならパーサーを再利用するのがベストだけど、ちゃんとやるならパーサー自体を独立したライブラリとして実装すべきだよね。意味解析まで含めて出荷できれば最高だし！実装の乖離は間違いなく問題になるから。でも素晴らしいプロジェクトだよ、議論に参加したくて意見を言わせてもらったよ！

企業の投稿で「どういたしまして（You're welcome）」って書いてあるの、最高に笑える。

Protobufから量子コンピューティングまで、Googleは「誰も困っていない問題」を解決し続けてるね……

なんて傲慢な投稿だろう。ProtobufのLSPなんて何年も前からあるっていうのに： https://github.com/lasorda/protobuf-language-server

ずっとProtobufってJavaのためのものだと思ってたよ。Javaではうまく機能してたけど、JS、特にKafkaと一緒に使うと相性が悪いんだよね。