面白いね。Goにはあまり詳しくないんだけど、Tauriに相当するものはGoの標準ライブラリにあるの？ユーザーケースに応じて、フロントエンドはGoで、バックエンドだけRustでやるのはアリかな？

標準ライブラリは、良いアイデアが消えていく場所だよね。それから httplib3、httplib4 が続く。つまり、私は Rust のアプローチが断然好き。標準ライブラリに依存するか他の依存関係に頼るかは、私にとってあまり重要じゃない。結局、依存関係なんだから。人々は、標準ライブラリだからって品質が良いとかメンテナンスが行き届いていると思いがちだけど、これは別の話。結局はリソース次第。確かに、標準ライブラリはリソースが多いかもしれないけど、肥大化してメンテナンスが難しくなることもあるしね…

必要な機能を正確に提供する他のパッケージをいくつもインポートするのが、必要な機能の一部しか提供しない大きな標準ライブラリを使うよりも悪い理由って何なの？

パッケージ管理はほぼすべての言語や技術の厄介な問題だよ。誰も「解決」してないし、これからも解決策は出てこないと思う（でも、何事も可能性はゼロじゃないよね？）。Go では、ライブラリの開発者がセマンティックバージョニングを正確に守ることに頼ってるし、バージョンを「固定」できないのが個人的に不満。いくつかの回避策はあるけど、SHA を使って疑似バージョンを提供したり、ベンダリング（既知の依存関係のキャッシュで、キャッシュ管理の問題もある）をしたりすること。週末に Python を仮想環境で使わなきゃいけなかった不運があったけど、うまくいかなかったし、Python から移行した理由を思い出させてくれた。Perl（cpan）、Java（maven, gradle）、Ruby（gems）、Go（dep, glide, vgo, modules）、Rust（cargo）、Node（npm, yarn など）、OS も Redhat（yum, rpm など）、Debian（apt）、Ubuntu（snap - なんでこれが必要なの？？）などなど。

Rustのライブラリは多くのクレートから成り立っていて、それが依存関係グラフに影響を与えることに注意してね。これが実際よりも依存関係の数が多く見える原因なんだ。別々のクレートは同じメンテナーが管理していて、しばしば同じ上流のgitリポジトリに属しているからね。とはいえ、一般的な意見には同意するよ。Rustには、半ばメンテナンスが行き届いてない0.xバージョンのクレートもたくさんあって、代替手段がないことが多いから。

rusqlite（sqlite）、clap（cli）、ratatui（tui）、tauri（gui） これに匹敵する標準ライブラリを持つ言語って、Java以外にあるの？それに、Tauri自体が14のクレートで構成されていて、それぞれがビルドツリーに表示されることも忘れないでね。 https://github.com/tauri-apps/tauri/blob/dev/Cargo.toml そしてRatatuiは6つだよ: https://github.com/ratatui/ratatui/blob/main/Cargo.toml

RustのLLMに対する弱点はコンパイル時間だね。LLMはコードを書くのが早いから、比較的コンパイルを待つ時間が人間よりも多くなる。だから、適度なサイズのプロジェクト（例えば、10万行以上）では、Rustのコンパイルが約10倍遅いことがボトルネックになってくる。重要なインフラを作るなら、そのコストを払うのは意味があるけど、内部サービスでインターネットに公開されていないものを書くなら、開発のスピードがもっと重要かもしれない。（遅いコンパイルが人間の開発速度にも影響すると思うけど、なぜか開発者はこれを定量化しようとすることがめったにないんだよね。）

詳細なコンパイラーエラーと強力な型システムのおかげで、変更 -> コンパイル -> 変更のループがエージェントにとって簡単に扱えるんだ。Rustはユーザーを強く制約するレールを提供してる。Codexはいつも何かをコンパイルさせることができるんだ。ただ、時にはイディオム的なアプローチが無理なときに失敗すべきだと思う…その代わりに、コンパイルできてリクエストを満たすような愚かな実装をすることがあるんだよね。

Rust には三つのエラーシステムはない。ひとつだけ、Error トレイトがある。io::Error はその実装の一つで、特別なものじゃない。thiserror で定義されたエラーもこれを実装してる。「Anyhow」は、関数が返すエラーの型を指定する API コントラクトを書くのが面倒なときに「何らかのエラー」と便利に言えるようにしてくれる。

Rust には統一されたエラー型がない Rust には実質的に一つのエラーがあって、それが Error トレイト。あなたが挙げたのはその使い方の一般的な例だけど、Box（基本的に anyhow::Error だね）だけでも全然問題ないよ。

同意する！最初の方で「バックエンドサービス向け」って言ってたのが気になった。Rust言語が大好きで、組み込みファームウェアやPCアプリに使ってるけど、ウェブバックエンドにはPythonを使ってるんだ。RustにはDjango（またはRails）に匹敵するツールセットがないからね。Flaskの類似品はあるけど、Flaskのエコシステムほど強力じゃないし。Goにはあまり経験がないけど、ウェブバックエンドにはRustよりGoを選ぶと思う。理由は同じくライブラリ（フレームワークを含む）エコシステムのためだよ。標準的な理由でAsync Rustのファンでもないしね（Rustのウェブエコシステムはほぼ完全にAsync必須だから）。

自分にとって、GoのRustに対する主な利点はコンパイル速度だね。それに比べると、Rustは多くのCやC++ライブラリに依存しているから、クロスコンパイルや再現可能なビルド、静的バイナリの生成が問題になることがあるんだ。Goのマイナス面は、GCがあまりにも単純すぎること。レイテンシスパイクが発生したときに、痛いリライト以外の対処法がほとんどないのが辛いよね。

しばらくGoの大ファンだったんだけど、最近SwiftやRustをプログラミングしてみて、ヌルポインタの参照を防ぐ保護がないコンパイラーや、並行性の安全性を保証しないコンパイラーはちょっと原始的に感じるようになったよ。でも、Goは標準ライブラリの面ではRustよりずっと良くやってたね。

thiserrorとanyhowは、ただのstd::errorにちょっと手間を加えたものだよ。io::errorは特定のstd::errorに過ぎないことに注意してね。Rustの全体のポイントは、Errorの実装を他のErrorの実装でラップしたり、matchを使って一つの実装を別の実装に変換したりすることなんだ。自分のエラータイプを十分に厳密に作れば、実際のバックトレースのオーバーヘッドなしで、ほぼ完全な意味的バックトレースが得られるから、これは他の多くの言語よりもずっと柔軟で検証可能だと思う。私はこのエラー処理を手伝うためにthiserrorをよく使うよ。特に、これがやることはDisplayとErrorを実装することだけだからね。特定の他のパラダイムではなく、基本的にコンパイルアウトされるマクロなんだ。anyhowは、型情報を捨てて文字列メッセージだけにすることができるから、他のパラダイムに最も近いかもしれないけど、それでもErrorsとよく統合されてる（そしてそれ自体がErrorsなんだ）。

バックエンドのウェブ開発には利点があるよね。Axumの型の使い方がすごく好きなんだ。例えば、こんな感じで書けるのがいいね：

pub async fn dataset_stats_handler(
    Path(dataset_id): Path,
    Query(verbose): Query,
) -> impl IntoResponse { ... }

ルートはこんな風に設定できて：

.route("/datasets/{dataset_id}/stats", get(dataset_stats_handler))

この「dataset_id」パス変数がそのままdataset_id引数にパースされて、クエリ文字列の「verbose」がブール値に変換されるのが超便利。Goと比べると、型の検証も一緒にできるしね。他にも良いところがたくさんあるよ。context.Contextがないこととか、ハンドラーがそのままレスポンスデータを返せることとか。あんまり好きじゃないのは、非同期処理かな。

面白いことに、全てのRustのソースコードはアセンブリの構文エラーに見える。

Goが大好きで、LLMベースじゃないものにはたくさん書いてたんだ。今はエージェント的なコーディングがあるから、すべてRustで書いてて、すごく満足してる。Rustを書くのは大変だったけど、Goは中堅エンジニア向けに簡単に書けるように作られてたからね。今はエージェント的なコーディングがあるから、Goの価値がどうなのか分からなくなってきた。私のRustサービスはパフォーマンスと信頼性の面で素晴らしいものになってるよ。

JVMやCLRのエコシステムからGoに移るのは、私にとってはダウングレードだね。言語設計はOberon（1987年）やLimbo（1995年）の文脈では意味があるけど、今はStandard MLやLispの遺産を基にした選択肢がたくさんあるのに、Goに妥協するのはダウングレードに感じる。1986年からコーディングしてるけど、ボイラープレートのエラーハンドリングや、定数値を宣言する唯一のメカニズムとしてコストが必要なら、選択肢はたくさんあったよ。

チームが C#/Java/Go などでうまくやってるのに、Rust を使う理由が見当たらないな…

実際、これ素晴らしいね。リンクありがとう！

これは完全に話が逸れちゃったけど、「正確に言う価値がある」というのは、「genuine」という言葉の使い方よりもずっと強い AI 的な表現だね。

最近、LLMの文章が表面や特に基盤について話す傾向が異常に高いことに気づいたんだ。LLMが生成するテキストがクリシェで溢れているのは期待してるけど、みんながもう少し編集に気を使ってくれたら、同じ声を何度も読むことがなくなると思うんだよね。

この投稿は全部AI生成だと思う。著者はドラフトを入力して、いくつかの部分を編集したのかもしれない。例えばこの段落を見てみて：> Goは1.18でジェネリクスを手に入れたけど、実装には制約がある（型パラメータを持つメソッドがないとか、GCの形状スタンシルとか、時々驚くようなパフォーマンス特性がある）。Rustのジェネリクスはモノモーフィズされて、各インスタンスはゼロランタイムコストで特化したコードを生成する。トレイトと組み合わせることで、本当にゼロコストの抽象化が実現できる。どの文も意味があるし、重要で、ちゃんとした重みを持ってる。こういう書き方は、専門的な本や論文から期待するもので、ブログ投稿からは期待しないよね。それに、投稿を読むのが難しく（しかも退屈に）なる。

ここには同意するけど、理由はよくわからない。何がAI生成っぽいのか全然わからないんだ。「Goは多くの人にとって明らかに機能している」ってところまで行ったときに、AIアシストかもって疑い始めた（でも、もしかしたら間違ってるかもしれないし、AIアシストじゃないかもしれない。そういうのを見抜くのが苦手なんだ）。何かが「AIアシストっぽい」って感じると、記事自体が良くても興味を失っちゃう。もっと自分の考えを素直に書けるようになればいいのに。

記事を読んでいると、何度かLLMが生成した文章を読んでいる気がしたけど、全体的にはこの特定の記事は許容できるLLMの使い方の例だと思う。これを「AIのゴミ」って呼ぶつもりはないよ。正直言って、LLMのアシストを使って、テキストがLLM生成に見えないようにするのは本当に難しい。Gmailでメールを書くときに、テキストを良くするための提案が出てくるけど、それぞれは個別に見ると完璧に意味が通る。でも、いくつかをクリックすると、全体のメールがAIのゴミみたいに見えちゃうから、普通は変更を元に戻して、自分の不完全な手書きのバージョンに戻るんだ。

それに加えて、他にもいろいろあるよね。私もそう感じたし、彼がリンクした「とにかくGoを使え」っていう記事との対比がいいと思う。Goの記事はもっと人間的だよね。そういうのが好きで、LLM中心の文化よりも人間中心の言語や文化を選ぶと思う。やっぱり私はただの古い人間なんだな。

Nodeの私たちは、静的コンパイル型が欲しくてTypeScriptを取り入れたんだ。TSにもっとランタイムがあればいいのに。Pythonに関して唯一嫉妬してるのは、HTTPエンドポイントでJSONスキーマの強制がこんなにスムーズにできること。Zodの手間は、TSチームが教条的だからこそ存在するイライラの元だよ。

PureScript経由でNodeを使うのは大丈夫かも？でも一般的には、RustとGoの人たちは動的型付けの悪に対抗するために力を合わせるべきだと思う。タイプヒンティングは今やベストプラクティスと見なされてるんじゃない？それは実質的に欠陥を認めてるってことだと思う。良いヒンティングがあっても、推論よりは劣るし。推論を使えば、型が変わっても多くのコードをそのままにしておけるし、意図しない型変更からも守ってくれる。

LLMの使用がRustの利用を爆発的に増やしたね。自分でコードを書かずに、みんなが楽しんでると思うけど、そんな中で「よりパフォーマンスの良い言語」を選ばない理由は何だろう？（現実ではそうじゃないけど、一般的にはそう見られてるよね）。LLMがあなたのために色々なものを組み合わせてくれるとき、Goの管理されたランタイムはあまり価値がないよ。async Rustを書くときに、多少の粗さがあっても全く文句を言わないしね。

結局のところ、RustとGoの比較は「管理されたランタイムが欲しいかどうか」にほぼ完全に集約されるよね。Rustを使っていると、Goのランタイムの半分くらいはガベージコレクターが不要になるし。いくつかのクレートを追加すれば、Goのランタイムから得られるものの約95%を手に入れられるよ。Goは世界で最高のランタイムを持っている。そこは認めるけど、これが唯一の理由じゃないよね…

RustとGoの比較は「管理されたランタイムが欲しいかどうか」にほぼ完全に集約される。それはあんまり気にしてないかな。Goに対する不満は90%が言語自体の構文についてで、Rustと比べると型システムが弱いことだよ。管理されたランタイムについては、ほとんどのタスクでは、言語にそれがあるかどうかはあまり気にしてない。気にするタスクもあるけど、それは少数派だし、だからGoとRustを比較する際にはこの質問はほとんど関係ないと思ってる。GoとRustの議論がランタイムについてだとはあまり思えない。私の経験では、言語自体やそのエコシステム、コミュニティに関する主観的なことが多いと思う。 > RustとGoの対立は、私たちの分野の奇妙で気まずい後進的な部分だね。::shrug:: まあ、私はあんまり関わらずにRustを使ってて、幸せだし、ドラマを避けてる。少しGoを書いたこともあるけど、あんまり好きじゃなくて、次に進んだよ。

その通り。プログラマーの95%はアプリケーションプログラマーで、普通のユーザーが使うソフトウェアを出荷してる。ほとんどのケースで非GC言語を使うのは狂気だと思う。手動のメモリ管理は精神的に負担が大きくて、致命的なミスをするのも簡単だからね。そのメリットは、ゲームやトレーディングシステムを作っている場合を除いては、全く価値がないと思う。5%の人たちが他の95%のためにツールやインフラ層を書く場合は、そのメモリ管理のコントロールが必要かもしれないけど、本当に必要な場合を除いて、その複雑さに関わる意味が分からない。

内部を隠すのが嫌になってきた。APIの安定性が保証されてないことが明確になる名前空間に入れて、必要なら使えるようにしておけばいいのに。君が言ってる通り、ちゃんと隠すのはただの苦痛で、得るものはない。ユーザーはバグを回避したり、機能を拡張したりするのが難しくなる。