そのリストにC#がないのは残念だね。

.debファイルを使ってD言語のコンパイラDMDをインストールできたよ。

これは、Wikipediaが今はGrokipediaがあるから意味がないって言ってるようなもんだね。

時々、x tuiコーディングエージェントがjs/ts/pythonで書かれてる理由がわからなくなることがあるんだ。どうせほとんどllmでコードされてるなら、Goを使えばいいのにって。でも、これは主にnpmが千の依存関係をインストールするのを待たなきゃいけないフラストレーションから来てるんだよね。一つの実行ファイルといくつかの設定ファイルで済むのにさ。プラットフォームごとに質が違うサポートライブラリ、例えばterminal uiもあるし。

アセンブリを書く方がいいよ。

「自分で暗号を作るな」っていうアドバイスがまだ良いとされてる限り、管理が必要なパッケージやライブラリは少なくともいくつかあるよね。でも、比較的普通のタスクに関しては、そういうのもありだと思う。

でも今はほとんどのコードがLLMによって書かれてるから、いつかはそうなると思うけど、今はちょっと難しそうだね。そうなってほしいな、だって今は一般的なソフトウェア開発者もまだいい給料もらってるから、一日中何もしないでその給料をもらえるのはすごく嬉しいよね！

コーディングエージェントのおかげで、Goに興味が湧いてきたよ。今、Goを使った中規模のサイドプロジェクトを進めてるけど、言語をほとんど知らない割には意外とスムーズに進んでる。Goの標準ライブラリはネットワークサービスやウェブプロキシを作るのに特に適していて、このプロジェクトにぴったりなんだ。

でも、今やほとんどのコードがLLMによって書かれているって 本当なの？それは大きな仮定に思えるけど。

でも、今やほとんどのコードがLLMによって書かれているから、LLMにとってPythonを書くのはRustやGoを書くのと同じくらい「難しい」 それでもLLMはPythonが提供する抽象化の恩恵を受けてる（トークンが少なくて、認知負荷も軽いから）。一つのモデルがPythonで書いて、別のモデルがそれをよりパフォーマンスの良い言語にコンパイルするパイプラインが機能するのが見えるね。

でも今やほとんどのコードはLLMによって書かれてるって言うけど、その大胆な主張を裏付けるものはあるの？

それに同意するわ。人間の使いやすさを考えた言語は、今後あまり流行らないだろうね。Goはここでかなり良いポジションにいるし、スティーブ・イェッジがその理由について書いてたよ。言語自体は速いし、PythonやTSよりも軽いし、JavaやKotlinほどドグマ的じゃない。LLMsはGoでバンバンやっても、コンパイラがほとんどの明らかなバグをキャッチしてくれる。コンパイルが速いから、プロセスをすぐに繰り返せるしね。それに、Goで達成しにくい抽象化が必要な場合は、Rustみたいにコストゼロであるべきだと思う。最近はPythonを書くことはないし、uvやpip、ty、mypy、ruff、black、その他もろもろを使う意味がわからないよ。Goのコンパイラと標準ツールがあの古びたPythonのツールよりもずっと良く機能するのに、なんでわざわざ面倒なことをしなきゃいけないの？スクリプトを速くするのもほとんどお金がかからないしね。Rustについてはまだどう感じるかわからないけど、LLMsがあまり得意じゃないからね。でもGoだと、エージェント的なコーディングはPythonやTSよりもずっと楽しいし、安全だよ。

私のLLMプロジェクトは100%Rustで書かれてるけど、実際にRustのコードを一行も書いたことがないんだ。コンパイルだけで、ソフトウェアの「カテゴリエラー」をいくつか排除できるからね。文法や変数宣言、型など。だから、過去10年間に始めたプロジェクトの大半でGoを使ってきたんだ。でもRustには、設計からくる二次的な保証があって、並行処理やnilポインタ、データ競合、メモリ安全性などに関するものがある。言語やフレームワークが導入するカテゴリエラーが少ないほど、LLMsがそれとやり取りするのが成功しやすくなるんだ。開発者は自由度や問題解決の方法が多いのを楽しむけど、LLMsは制約のある状況でこそ力を発揮する。ここでのフロンティアは、RustやC互換の言語の拡張で、面倒な言語機能を通じて問題のカテゴリ全体を解決するものになるだろうし、特に検証可能な出力を生み出し、LLMsから選択肢を排除するソフトウェアを構築・展開するものになると思う。

でも今やほとんどのコードはLLMによって書かれてるって言うけど、俺はトゥルーマン・ショーにいるの？プロダクションで動かしてるコードの1%すらAIが生成したとは思えないし、尊敬する人たちもそう言ってる。AIの例に強く影響されてるし、リサーチ中にAIにかなり助けられてるけど、そんなに成功してる開発者って誰なんだ？プロダクションでの「バイブコーディング」は、せいぜい無責任だと思う。

Python/JS/Rubyなどは、開発者の時間が重要だった時に良い選択肢だった。まず、これがこれらの言語の終わりだとは思わない。俺はまだほぼ毎日Rubyでコードを書いてるし、主に小さな問題を解決するために使ってる。Rubyはここで全てをつなぐ究極の接着剤みたいなもんだ。ただ、Rubyは絶滅の道を歩んでるのは確かだ。これはAIが登場するずっと前から始まっていて、いろんな理由がある。Perlの時もそうだったし、今はRubyが同じ道をたどってる。最近、RubyCentralがコミュニティに背を向けたことで、彼らを神のような新しい支配者として信頼するのが難しくなったのも一因だ。もうすぐRubyはSubyに改名されるかもね、Shopifyが主導権を握ってるってことを示すために。面白いのは、「Rubyは死んでない、Rubyは死んでない」っていう記事がまだ出てること。そういう記事が増えてるのが心配だよね。まるで最後のセールを売り込もうとしてるみたいで、その後に会社が倒産する感じ。人間の心って不思議だよ。PythonやRubyの良い点の一つは、アイデアをコードにプロトタイピングするのが得意なことだよね。その部分は、AIがもっとコンピュータに浸透してもなくならないと思う。

普段はLLMを使ってPython（かTypeScript）を生成してるよ。Cを出力させるよりも、質とメンテナンス性が格段に良いからね。やっぱり「人気」の言語以外ではあんまりパフォーマンスが良くないんだよね。

いつから仮想的で持続的な開発環境を提供し始めるんだろう…。多くの企業がこの方向に進みたがってるよね。機械の管理をする代わりに、薄型クライアントをたくさん用意して、Microsoftとかに実際の作業をホストしてもらう感じ。フロントラインのスタッフ向けにこういう「キオスク」スタイルのことはすでにやってるし。正直、開発用のローカルハードウェアがないのは地獄のようだけど、そういう方向に進んでる気がする。

Claude Code for the webは、すでに持続的な仮想開発環境みたいなものだね。そこでセッションを始めて、チャットしながら作業を進めて、翌日そのセッションに戻ると、仮想ファイルシステムが出発時と同じ状態になってる。これに時間制限があるのかはまだ分からないけど、オブジェクトストレージをうまく使って、環境を持続させるコストがすごく低いのかも。FlyのSprites.devも参考にしてみてね: https://fly.io/blog/design-and-implementation/

dioxusチームのために、mac/linuxの永続的かつ一時的な開発環境にVNCと強力なCPU/MEMを使えるように何か作り始めたよ。マルチプラットフォームを提供する人がいなかったから、本当に必要だったんだ！ https://skyvm.dev

— なんで核を発射してるの？誰も人類を壊滅させてくれなんて頼んでないよ。 — その通りだね。そんなことをするべきじゃなかった。発射を取り消す手伝いをしようか？ — はい！早く！やって！ — https://www.newyorker.com/cartoon/a16995

なんでそんなことするの？

そうだね、みんなが何かを発見して共有すると、プレスリリースやコメント以上に楽しいことがある。クリエイティブでインスパイアされる投稿だね。

PS6を6台どう？

まあ、どっちにしてもインフォセックの人たちは、レポートを書いたり、両方の側でたくさんお金を稼いだりして、最高の時間を過ごすことになるだろうね。サンドボックスからの脱出や、リモートコード実行のパス、情報漏洩の手法、そしてコードされた砂のお城が崩されるのを待ってるのが見えるよ。AIにプロンプトしてるコードの一行も知らないって公言してる人たちがいるからね。AIが全てのコーディングを担当することで、どれだけのセキュリティ問題が出てくるのか、その規模はまだ分からないと思う。