Zigの創始者は真実を語っているが、Anthropicは大ぼらを吹いている
(raymyers.org)- Anthropicがソフトウェアエンジニアリングの終焉を将来価値として掲げる中、BunのZig→Rust移行も、AIがエンジニアリングを代替できるという宣伝の物語に利用されたとの批判がある
- Bunはメモリバグを移行理由に挙げたが、代替案と長所・短所の比較が不足しており、Rustの遅いコンパイルのようなコストも公開していないため、事後的な正当化に見える可能性がある
- Zigを別の形で運用する選択肢もあり、TigerBeetleのTigerStyleは静的メモリ割り当てとシミュレーションテストによってuse-after-freeを防ぐ事例を示している
- unsafe Rustでファイル単位に移植した方法は、リスクを減らし将来の再設計も可能にした合理的なアプローチだが、100万行規模のAI変換は受け入れつつ、人間が読める数行のポインタ管理コードを問題視する態度は一貫性に欠ける
- エージェントハーネス、Rustのborrow checker、可読性ルール、人間のレビューは引き続き必要であり、コーディングエージェント導入とソフトウェアエンジニアリング廃止は同じ選択ではない
Anthropicが掲げるソフトウェアエンジニアリング終焉
- Anthropicは、コーディングに続いてソフトウェアエンジニアリングや大半の人間労働まで消えるという物語を積極的に押し出している
- 同社は1,320億ドルの投資を呼び込み、企業価値1兆ドル超のIPOに近づいているが、収益性を示せていない状況で、仮想的な将来の影響力を売らざるを得ない立場にある
- こうした利害関係があるため、Anthropicは**信頼できない語り手（unreliable narrator）**として見るべきであり、メッセージの真偽だけでなく、それが経営陣・世界の指導者・年金運用者の判断に与える影響も重要だ
- AIの物語はアーキテクチャ・製品・人員配置の決定に影響し、解雇への恐怖や取り残されるという警告、Doom Trollingの中で冷静な判断を難しくする
- ソフトウェア分野のAIを評価する際は、Anthropicの利害関係と宣伝目的を踏まえた懐疑的な検討が必要だ
BunのZig→Rust移行と遅れた説明
- Anthropic/Bunは、Zigで書かれたBunをRustへ移す決定をメインブランチにマージしてから2か月後になってようやく説明した
- 大規模インフラプロジェクトであれば、事前に方向性を説明するのが一般的だ
- 説明が遅れる間に、Anthropic’s Bun Rust rewrite merged at speed of AIのような見出しが、AIが再書き換えを素早く完了したという印象を広めた
- Zigの創始者Andrew Kelleyは反論を公開し、異例なほど率直な口調でBunの技術と組織運営を批判した
- 言語を変えたという理由で、以前の言語のリーダーが個人的欠陥にまで踏み込んで攻撃する前例になり得るという評判上の負担がある
- 一部はこれを「meltdown」と呼んだが、公に指摘すべき問題を指摘したと見る余地もある
率直な批判を判断する基準
- 仏教の正しい言葉（right speech）では、あらゆる発言が次の5つの基準を満たすべきだと考える
- 事実か
- 役に立つか
- 時宜にかなっているか
- 親切か
- 親切心から出ているか
- Andrew Kelleyの対応は事実だが不親切な言葉にあたり、通常の礼儀を外れていても問題を公に指摘する必要があったのかが争点となる
Bun・Zig・AI貢献ポリシーの関係
- Bunはより高速なNodeJSになぞらえられるTypeScriptランタイムで、ZigはモダンなCになぞらえられるシステムプログラミング言語だ
- Bunは最近までZigで書かれており、最大級のZigコードベースの1つだった
- 両プロジェクトのAI貢献ポリシーは正反対だ
- Bunはコード貢献のほぼ100%がAIだと明かしている
- ZigはAIによる貢献を許可していない
- AnthropicがBunを買収した後、創業者Jarred SumnerはZigコードをunsafe Rustへ移す大規模なエージェント実験を進め、その結果は数日後にマージされて正式版となった
- 関係者の中で、Bunを引き続きZigのまま維持すべきだと求める側は見当たらず、論争は移行そのものより、その理由と宣伝の仕方に集中している
- エージェントを使った大規模な言語移行は、条件が適切なら再び試す価値のある技術的実験だ
同じ決定をめぐる3つの解釈
- ZigとRustのどちらかを選ぼうとしている開発者にとって、最大規模のZig利用者の1つが判断を覆した出来事は重要な判断材料になる
- Anthropic/Bunの解釈は、合理的な方法をすべて試したが、Zigではメモリバグに対処しきれなかったというものだ
- Andrew Kelleyの解釈によれば、AIエージェントにコード作成やレビューを過度に任せるなど、Bunのエンジニアリング上の判断のせいでコードベースが荒れてしまった
- よりありふれた可能性は、実際のメモリ問題に複数の解決策があったものの、経営陣にとってRustへの再書き換えを選びやすかったということだ
- 新しいFableモデルの能力を宣伝できた
- AnthropicはすでにRustを使っていた
- ZigプロジェクトはAnthropic製品の利用に公然と反対している
- Rust移行は事業的には合理的かもしれないが、宣伝はAIが再書き換えを実行できるほど強力だという点に集中している
- AIがuse-after-freeを事前に見つけられなかったという事実は、この物語と衝突する
- Anthropicの拡声器による誇張は、Jarred SumnerとAndrew Kelleyの判断を直接比較させることになり、意図せずZigの評判にも影響しうる
技術論争に個人の信頼性が入り込んだ理由
- まず責任を問うべき主体は、Bun創業者個人よりも、この出来事をAIの物語に利用するAnthropicだ
- AnthropicがJarred Sumnerの信頼性を利用して自社メッセージを強化している以上、これに対抗するには彼の判断と行動も評価せざるを得ない
- 技術的論点だけを議論するのが望ましいが、Anthropicのメッセージが技術比較よりも見せ場と宣伝に依存するなら、個人の信頼性まで論争に入り込む
- 当事者が公にした発言と行動を整理しただけで中傷のように見えるなら、その行動自体も問題の一部かもしれない
常態化したクランチとBunの組織環境
- Bunの2022年の採用告知は、最初の9か月は非常に厳しく、働かない時間が多いタイプのワークライフバランスを重視するなら向いていないと警告していた
- 常態化したクランチモードは健康にも生産性にも有害であり、知的労働に関する実証研究でも繰り返し確認されている
- 関連資料としてEmpirical Software EngineeringのHuman Factorsの項を参照できる
- 週90時間勤務を誇る管理者より、メンバーが夜に眠れるよう守る管理者を選ぶべきだ
- Andrew KelleyがBunチーム関係者から聞いたという評価は、コミュニケーション不足、非現実的な期待、低い共感、経験不足に要約されるが、伝聞であるという限界がある
- ただしこの評価は、採用告知で公開されていた極端な労働環境とも一致している
- 悪い労働環境でも優れた技術が生まれることはあり、Bun自体は実用的で興味深いツールだ
- コードにバグが多く保守しにくかったという評価は、外部の批判にとどまらず、BunがRust移行の根拠として掲げた状態でもある
unsafe Rust移植方式の実質的価値
- 移行過程の技術的な詳細は、他のモダナイゼーション・プロジェクトにも再利用する価値がある
- Bunは最初から安全なRustへ再設計するのではなく、unsafe Rustによるファイル単位の移植を実施した
- 既存の構造を維持して初期移行のリスクを下げた
- その後に安全性を改善し、再設計できる基盤を整えた
- AIベースの自動化によって、言語選択を過去より容易にやり直せる可能性はあるが、自動書き換えには依然として長所短所と意味の差異がある
- 複数の書き換え手法を組み合わせ、形式手法（Formal Methods）で強化することも可能だ
- DARPAのTRACTORは、すべてのCコードをRustへ移す研究プログラムであり、公開されている評価報告書は自動変換技術の現状を扱っている
- エージェントが古いコードにより多くの選択肢を与えるとしても、モダナイゼーションの目標を定めるには判断とコミュニケーションが引き続き必要だ
- 関連する参考書はMarianne BellottiのKill It With Fireである
穴の多い技術的意思決定文書
- 技術的な決定を説明するには、少なくとも3つの要素が必要だ
- 動機は何か
- どのような代替案を検討したか
- 各代替案の長所と短所は何か
- Richard FeldmanがRocコンパイラをRustからZigへ移した理由を整理した文書は、3要素をすべて備えた比較事例である
- Bunの説明は、メモリバグという動機は示したが、検討した代替案は一部しか扱っておらず、長所短所の比較は事実上欠けている
- 特に長所短所を省くと、最初から答えを決めて後から根拠を付けた事後的正当化のように見えるおそれがある
- 公開していない別の理由がある可能性も排除できず、決定の信頼性を高めるには不利なコストまで含めて明らかにすべきだ
Rustの長所だけを並べた比較
- 「Bun is better in Rust」の部分は、Rust移行の利点だけを扱っており、コストはほとんど示していない
- 大規模なRustコードベースは、一般に安全性を得る代わりに遅いコンパイル時間というコストを支払う
- Bunは過去にコンパイル速度を重視し、Zigコンパイラをforkして4倍の改善を試みていた
- Rust移植によってコントリビューターのビルド時間が増えたのであれば、それを公開し、そのコストより安全性が重要である理由を示すことで、決定の信頼性は高まる
- 移行後に行われた他の改善までRust書き換えの長所一覧に混ぜ込むことで、言語変更の直接的な効果が誇張される可能性がある
検討されていないスタイルガイドという選択肢
- Bunではメモリバグが唯一の欠陥原因ではなかったが、個人集計では週あたり4件の修正コミットが必要になるほど頻繁だった
- 各メモリバグは、オブジェクトの生成・所有・解放方式に関する規約がどこかで破られたことを意味するため、状況ごとの期待動作を明確に定める方法から検討できる
- 手動メモリ管理は規約の範囲を広げるが、言語に関係なく効果的な使用指針が必要であり、RustにもAPIスタイルガイドがある
-
TigerBeetleが示す代替案
- もう一つの代表的なZigコードベースである金融トランザクションデータベースTigerBeetleは、メモリバグに悩まされておらず、最も信頼性の高いデータベースの一つに見える
- TigerStyleとシミュレーションテストを信頼性の基盤としている
- TigerStyleは単なるコーディング様式ではなく、設計・メモリ・テストを束ねたエンジニアリング哲学である
- すべてのメモリを開始時点で静的に割り当てる
- 初期化後は動的割り当てや解放後の再割り当てを許可しない
- 予測しにくい性能変化を避けつつ、use-after-freeを防ぐ
- 可能なメモリ使用パターンを設計段階で考慮することで、より単純で高速かつ、推論と保守がしやすい構造を促す
- すべてのアプリケーションがこの方式をそのまま適用できるわけではないが、メモリポリシーが全体の設計判断とつながっていることを示している
-
Bunの説明に残る空白
- BunはTigerStyleとGoogleの31,000語に及ぶC++スタイルガイドに言及したうえで、スタイルガイドは強制が難しく、伝統的にはコードレビュー・リンター・静的解析器に依存するとまとめている
- しかしBunが実際にどのようなスタイルガイドを使い、なぜ失敗し、4年間でどう改善したのかは扱っていない
- 大きなプロジェクトでメモリ問題が続いていたなら、現在の言語を別の使い方で運用する選択肢を真剣に試したかどうかが重要だが、それを裏付ける根拠が不足している
- 一人の人間がすべての文脈を頭の中に保持し、会議をしない運営方式は、明示的な規約と共有された設計を作りにくくする
エージェントレビューとスタイルガイドの矛盾
- Bunはスタイルガイドの強制は難しいと見なしながらも、移行用の
PORTING.mdを作成し、エージェントが全書き換えコードを厳格な指針に従ってレビューしたと明かしている PORTING.md自体が移行範囲に特化したスタイルガイドであるため、エージェントレビューが成功したなら、指針の強制という問題もすでに解決していることになる- 適切な条件では、エージェントレビューは機能しうるが、十分に設計されたルールとレビュー方式が前提となる
- 同じ精神的努力をZigコードの再設計や規約強化に投入することもできたはずだが、Bunは再アーキテクチャではなく書き換えを選んだ
- 公開されていないさまざまな理由によって書き換えが正しい選択だった可能性はあるが、現在の説明だけでは代替案の比較が十分ではない
100万行の書き換えと3行のポインタコード
- Bunは、Zigで所有権の期待を型レベルで表そうとすると、
SharedPtr(TCPSocket)やderef()のようなコードが追加され、既存のポインタ利用より不便になると見ている - この例では、インターフェース境界でのポインタ受け渡しを明確にするために、おおよそ3行のコードが増える
- レビューが難しい100万行規模のAI生成PRは受け入れながら、ポインタ所有権を明確にする数行を可読性の問題で退ける姿勢は一貫性に欠ける
- Jarred Sumnerは、数か月の間、人間が直接コードを入力していなかったと明かしている
- コードが人間のためのものでないなら、
SharedPtrラッパーが見づらいという理由は弱くなり、人間のためのものなら、可読性・レビュー可能性・保守性を引き続き考慮しなければならない - AI企業は、コードの可読性が依然として重要だという事実を認めたがらないが、これを否定するとソフトウェアエンジニアリングが終わるという物語には合っても、保守の現実とは衝突する
- コーディングエージェントが基本的に保守性を悪化させうるというベンチマークもある
同じ出来事が示す「AIだけでは不十分だ」
- Bunの大規模なエージェントによる書き直しは、技術改善だけでなく、Anthropicが「AIで十分だ」というメッセージを宣伝するという事業上の機能も果たしている
- しかし、同じ事例はまったく逆にも解釈できる
- LLMだけでは不十分なので、エージェントハーネスで包む
- AIだけではメモリ安全性を保証できないため、Rustのborrow checkerを選ぶ
- 人が読まなければならないため、ポインタラッパーの可読性を気にする
- 人が保守しなければならないため、従来どおりで馴染みのあるコード構造を重視する
- Project Bunsenはハイブリッドアプローチによって、Zig版Bunで50個のバグを発見した
- オープンソースのメンテナーは、AIスロップが生む負担、コントリビューター検証の問題、AI貢献の選別ポリシー、生成AIポリシーの整備への対応を進めている
- エージェントが作った問題まで、さらに多くのエージェントで解決できるという前提のもと、より良いツールの代わりにトークンを買い、技術を学ぶ代わりに
SKILL.mdを付けるやり方が広がっている - ソフトウェアチームの心理を理解する代わりに、並列エージェントセッションをTeamと呼ぶのは、人間の組織と自動実行セッションを混同している
コーディングエージェントの導入とエンジニアリングの放棄は別問題
- Anthropicのソフトウェアエンジニアリング終焉キャンペーンは、AIツールを作る側にも使う側にも逆効果をもたらしかねない
- コーディングエージェントを導入するとしても、人がコードを理解しないDark Software Factoryを理想モデルにする必要はない
- 目標は、人々が望むものを作り、それをきちんと動くようにすることであり、AIバブルは望まないものを低品質で作るよう圧力をかけかねない
- AIを活用しつつも、判断・学習・コミュニケーション・可読性・保守性を手放さない方向が必要だ
4件のコメント
AIがRustをうまく扱えることはあるでしょう。ただ、トークンを大量に消費するだけで……いかにもAnthropicらしい選択だと思います。
何か記事を読みに来たときとは印象が変わりましたが、メモリの話が繰り返されているのを見ると、なぜそういう選択をしたのかは理解できます。結局、メモリ管理を直接行うのは、AIを走らせたときにミスする確率が高いのは事実のようですからね。単にRustでコンパイル時に検出する方法を選び、AIをよりうまく使えるようにしたということなら理解できます。AIでコーディングすることとは別に。
Rust万歳、万々歳
Hacker News の意見
この記事には良い内容が多いが、数か月で放置される AI 生成プロジェクトを思い起こさせる。プロジェクトの価値は生成されたコード量よりも、実運用でどれだけ検証されたかにあり、成熟した既存コードのほうが新たな再実装より優れている。
既存の Zig コードベースはすでに検証済みだが、Rust での再実装はテストに通ること以外ほぼ検証がゼロに近く、
unsafe Rustでファイル単位の直訳をしたのなら、出発点である Zig より何が優れているのかも不明確だ。その後、安全な Rust に移し、運用環境と多数のユーザーに検証されて初めて意味が出てくる。実質的には Bun がフォークされたようなもので、Zig 版と Rust 版のどちらが生き残ろうと構わないし、これを Zig の適性の問題として受け止める理由もない。
平凡なプログラマーである私でも毎日何十もの素晴らしいアイデアを思いつくが、検討に耐えるものはごくわずかで、数日後にはそれさえ努力する価値がないように見える。アイデアはもともと安価で、今では概念実証まで安価になったので、1か月も投資していない Show HN には関心が持てない。
Zig 陣営は、C に対する利点が十分ではなく本格用途に使われず、代表的なプロジェクトまで離れたため、Zig は最初から見込みのない言語なのではないかと心配しているように見える。Zig のイシュートラッカーで
segfaultを検索してみれば、Rust のような代替案を前に将来の有用性を疑う理由が分かる。unsafe境界があり、それを一つずつ直していける点のほうが優れている。反 AI 陣営を諭すためにメッセージを管理しているわけではない。
Andrew が率直に言ったこと自体より、記事が明らかな個人攻撃でありながらそうではないと主張する二重姿勢のほうが大きな問題だ。
この記事を読んで、Zig で何かを作りたいと思えなくなった。どんな技術的判断をしても、Zig の終身の慈悲深き独裁者（BDFL）がこういう文章を書き得るからで、Python や Rust など他のコミュニティの指導部がこのように振る舞う姿は想像しにくい。
誰かは Andrew が Bun を攻撃したと見なし、私は Andrew への反応を個人攻撃と見なすこともできる。先入観を取り払えば、双方がどちらも間違っていた、またはどちらも間違っていなかったと見るべきであり、遠くから状況を判断するときは、個人の先入観が過度に大きな影響を与えることを意識すべきだ。
Andrew 側に立ちたい。Sumner の仕事を何年も見てきた立場からすると、Kelley の批判は不親切ではあってもかなりの部分で事実であり、成果物が有用で素晴らしいものであっても、最初から最後まで自己宣伝のための影響力行使に近かった。
私自身も 1 日 8 時間エージェントベースの開発をしており、チームには Node の代わりに Rust と Deno を使おうと勧めてきたが、この再実装は正当化が弱く、Dario たちが成功させた長い宣伝戦の延長線上に見える。表現をもっと穏当なものにしていれば受け入れられただろうが、広報チームが代筆した文章ではなく率直な考えを出した点は高く評価する。
JavaScript ガベージコレクタと相互作用することで Bun 固有の難しさが生じるという説明は有用だったが、Andrew はこれをまったく扱っていなかった。新しいコードを既存のテストスイートで検証したという説明も、テストまで雰囲気コーディングで翻訳されたため信頼できないと思っていた誤解を解いてくれた。テストがすべてのバグを見つけられないという事実は、Zig を含むあらゆるソフトウェアに当てはまる。
結局、メモリ安全でない言語が莫大な欠陥コストを生むという見方と、「腕を上げてバグを書かないようにせよ」という対応の衝突に、AI 論争、Anthropic の関与、Andrew の Linus 風の物言いが加わって広がったのだ。
Anthropic と Andrew Kelley の文章を同じように読んだのか疑問。Anthropic はプログラミング言語を売る会社ではなく、Bun の Rust 書き換え記事には、最終ユーザーにとって製品がどう改善されたのかを示す技術的詳細が多かった。
一方で Zig 側の反応は、個人攻撃に満ちた辛辣なコラムに近い。私は Codex を使っており、Zig にも Rust にも利害関係がないので、外から見ている立場だ。
また、成功した書き換えを宣伝する際には、既存コードがどれほど悪かったかといった、物語に不利な要素を隠すことが多く、今回も重要な側面が抜け落ちている。
Andrew Kelley の記事（https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...）は、Jarred の低いエンジニアリング基準、Zig 財団との会議を連絡なしに欠席するなどの不十分な対外関係、Rust への移行過程で Zig を悪い選択肢であるかのように描いたことで生じた損害、それに伴う ZSF の怒りを扱っている。
表面的にだけ見れば、言語の創始者が元ユーザーを攻撃していると懸念するのも当然だが、Bun の記事だけを読んで私も抱いたその印象がなぜ不当なのかを Kelley は明らかにした。一部に個人攻撃があるのは確かで、後から追加された最後の節でもそれを扱っている。
Java、JavaScript、Python、C# は、完璧主義ではない開発者でも大事故を起こさず働ける安全装置を提供し、C++ 中心の産業を掌握した。C と C++ の性能上の利点は大きかったが、ますます敵対的になる環境の中でかなりの熟練を必要とした。
Rust と Swift は、ガベージコレクション言語より性能の予測可能性が高く、同等かそれ以上の安全性を提供した。そして Rust のアイデアは、この領域で新しい言語が爆発的に登場するきっかけになった。ただし、その多くは産業上の要求から出発した Rust よりも職人気質に近い。
車にたとえるなら、Java や JavaScript などは一般的な安全車両、C/C++ は二輪バイク、Rust は速いが乗員を守るラリーカー、Zig は四輪バギーやオープンホイールのカートに近い。簡単にスリップはしなくても、横転すれば非常に危険だ。
時間とコストの制約を無視する職人たちは、慎重な開発者だけがいれば十分だと考えるが、産業の現場では、良いコードを書けるとしても 90% は制約の中で作業するため、自分のコードであれ他人のコードであれ信頼しにくい。Zig には多くの長所があるが、最初から安全性よりハッキングの自由を好む人たちのための言語だった。
メモリ安全性も、AI、テスト、そして高レベルのファジングではなく、Zig チームが推奨した統合ファザーを使っていれば、同じように確保できた可能性がある。それでも Bun のようなプロジェクトには、より成熟した Rust が良い選択かもしれない。
何が起きたのかを理解するには Andrew の視点が不可欠だった。表現の一部はもっと穏やかにできたかもしれないが、悪いマネジメントが関係悪化とお粗末なエンジニアリング結果の直接の原因なら、それを明らかにすることは個人攻撃ではなく、必要な文脈だ。
特に Zig の指導部はバイブコーディングを公然と嫌い、業界を批判しており、プロジェクトはその製品で作られた貢献リクエストを拒否している。
この論争には肝心の技術的な実体が不足している。Bun の Rust 移植にも、Andrew の攻撃的な文章にも、ゴールドラッシュでシャベルを売る Anthropic にも関心はなく、具体的な技術内容が見たい。
Jarred が示した Rust 移行の動機は、根拠がやや不足していても妥当に見えるが、Andrew はそれが実際には問題ではない理由や、Zig で正攻法としてどう解決するのかを反論していなかった。特に Bun の実際の Zig コードに基づいて論点を分析してほしい。
Bun は Zig の経験が乏しい人物が、巨大な範囲と複雑さにもかかわらず始めたもので、最初から別の言語のコードを書き換えたプロジェクトだった。esbuild の JavaScript・TypeScript トランスパイラを Go から Zig に一行ずつ移植した後、数年でコードベース全体を捨ててさらに別の言語で書き換えたのだとすれば、これ以上何を論じることがあるのか疑問だ。
Bun はシェル言語、SQLite/PostgreSQL クライアントのような機能をできるだけ早くリリースしようとしているため、メモリ管理を直接気にしたくない。Zig はメモリ管理と寿命を直接扱わせ、
Dropのような機能も意図的に追加しないが、Rust はDropのおかげでより適している。Python で SQL データベースを作らないのと同じように、Zig は Bun に合った道具ではなく、Zig で正攻法として解決するような話というより、Jarred がプロジェクトを素早く展開しようとする方法の違いだ。
Kelley の見解の一部には同意するが、問題は語調だ。
Bun が Rust から Zig に書き換えられたのだとしたら、Rust のコアチームメンバーが Sumner を狙った個人攻撃の記事を書き、それは攻撃ではないと主張した可能性は低い。Kelley に書きたい文章を書く自由があるのと同じように、成長中の言語の BDFL が作り出した Zig の公開イメージに対して、人々が反応する自由もある。
Bun の Rust 移行に関する記事は、具体的な選択肢の比較や影響の数値が欠けており、結果の扱いも偏っていて、エンジニアリングブログの記事のようには感じられなかった
人々は移植の技術的根拠よりもエージェント活用のほうに関心を示していたようで、技術的には非常に期待外れだった
経営陣や幹部におけるマーケティングの影響力がどれほど大きいか、特に CEO のような地位に就く人々がどれほど些細な感情に左右されうるかを過小評価してはいけない
新しい Fable モデルを宣伝する機会であること、そして Zig が Anthropic 製品の利用に公然と反対していることだけでも、Bun の Rust への書き直しは事実上決まっていた可能性がある
言語移行の議論で、なぜ勤務時間への期待値まで扱うのか分からない。彼がひどいマネージャーだとしても、否定的な材料を無理に探しているように見える
Zig 側が書き直し自体の技術的メリットにほとんど焦点を当てていないことも示唆的だ。Anthropic は複数の改善点を挙げていたが、それに反論しようとする試みすらほとんど見当たらない
自分のプロジェクトを大規模言語モデルで書き直したら、欠点なしに改善されたという結果が出たなら、私は大いに懸念して対応するだろうが、ここでは見当違いに勤務時間を論じている
Anthropic が所有するプロジェクトと、AI 生成コードに公然と敵対する言語コミュニティの指導部との間には、明白な利益相反がある
Andrew Kelley はこの点だけを述べて止めておくべきだったし、Bun 創設者のエネルギーや動機に関する評価はほとんど付け加える価値がない
Kelley もそれを分かっていたが、核心をぼかしたい誘惑に抗えなかったようだ。過激な記事（[0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...）は行き過ぎだったが、前に進もうという追記は健全だ。BDFL は過度に無味乾燥であるより、多少辛口なくらいがよいと思う