【衝撃】GoコンパイラのARM64版に潜むバグを発見！その全貌とは？

そうそう、ピュアなユーザーモードのスレッドプリエンプション（割り込み）を正しく実装するのはマジで難しいんだよね！それがGoのランタイムの一部だって知って感動したよ。

ほとんどすべてのユーザーモードの"スケジューリング"（async/await）を備えた言語が、協調的な方法を使ってるのには理由があるんだ...

Goって、モダンな言語デザインを無視することで有名じゃなかったっけ？

俺がGolangがRustよりも新しい言語だって知った時の反応。体感的には数十年前の言語なのに。

無視してるわけじゃなくて、再発見中って感じかな。

再定義って言う方が近いかも、うん。

それ、完全に Kool-Aid 飲んじゃってるって言うわ。

それを選ばなかった理由ね。作者が過去に作った言語のいくつかには、例えばジェネリクスが実装されてたんだ。それを実装した経験から、ジェネリクスは一旦置いとくことにしたんだって。

例えば、Robが関わった過去の言語の一つにLimboってのがある。Limboでのジェネリクスの動作例はこれ：https://github.com/henesy/limbobyexample/blob/master/Generics/generics.b

この人の言語を見て「こいつは新しい言語を作るのにうってつけだ」って思った人がいるなんて、マジかよ。

Googleくらい金持ってれば、どんな悪い決断だってできるさ。

そう、だって過去30年で開発された数々の素晴らしい言語機能を効果的に使いこなせる経験豊富なプログラマーが使うように設計されたんじゃないからね。シンプルさの名の下に、それらは意図的に捨てられたんだ。

そうじゃなくて、短期契約の請負業者がプロジェクトを拾って、機能をポンと作って、できるだけ早く次に行けるように、明確に設計されたんだよ。言語は欠点があるほどシンプルである必要があって、簡単にテストしてプロダクションに投入できる、低～中品質のコードを大量生産するのに適してる必要があるんだ。コードが実装する機能は、Googleがプロジェクトを棚上げするまで長く生き残る必要はないんだよ。コードの品質が重要になる前にね。

＞これは、僕らの問題がランタイムバグであるという決定的証拠のように感じられました。

記事から引用。

＞
＞
＞
＞
＞俺が細かいだけ？

そうは思わないな。最近よくあることになってきてて、ブログを読むのがマジで疲れるんだよね。

スケボーのトリックを初めて成功させた14歳くらいの少年が話してるような感じがするって思ってたのは俺だけじゃなかったんだ！:D

これは、マルチスレッドの競合状態がスタックの破損を引き起こした事件の調査の話で、（個人的には）調査する上で最悪で解決するのが最も難しいバグの1つだと思う。決定的に再現可能じゃないし、扱っている証拠には根本原因を特定するために必要な情報が含まれてないことが多いんだ。クラッシュした車を見つけて、クラッシュを引き起こした前の状態と一連の動作を特定しようとするようなものだよ。必要な情報がすべてクラッシュした車の中や上にあるわけじゃないんだ。

だから、調査の本質は、可能性のあるすべての原因をブレインストーミングして、可能性が高い順にランク付けし、スタックサイズ、メモリアロケーション、スレッド作成、ガベージコレクションなどを誇張して使用することで、失敗を引き起こす可能性を高める小さなプログラムを書くなど、合成的な手段で仮定された各原因を悪化させようとすることなんだ。仮定された各原因は調査され、さらなる証拠が得られるか、行き詰まるかのどちらかになる。行き詰まること自体も役に立つんだよね。

だから、「根本原因からほど遠い」という問題の詳細を説明する言葉の再利用や、「～だと確信していた」という最も可能性の高い原因を説明する言葉、「～は明らかだった」というテストから得られた事実の説明は、許容できると思う。とは言え、あなたは細かいことを気にしすぎだと思う。かなり詳細なブログ記事だし、俺が見た限りだと

～は明らかだった

は1回しか使われてないし

～だとかなり確信していた

は2回

（根本原因|実際の問題|クラッシュ）からほど遠い

はそれぞれの選択肢が1回ずつしか使われてない。

特に反復的だとは思わないし、

• 💪 プロっぽくないほどの — 絵文字の数
• 🚀 多すぎる —箇条書き
• ⭐ 常に太字の — 箇条書きリストの最初の単語
• 🏈 Emダッシュ — 見渡す限り

がないから、これはAIによって生成されたものではないと思う。完全に生身の人間が作った感じがするよ。

全部もっともな意見だね。それに、挙げられてる作者が、このトラブルシューティングに関わってた可能性が高い背景を持ってるのも理解できる。

彼の文体は、エンジニアリングや根本原因の分析スキルほど洗練されてないってのはあり得るし、それは全然許容範囲だと思う。それに、必要な編集が入って、あのぎこちない文体になったのかもね。

でも、最大手のクラウドプロバイダーの一つである企業のトップレベルのブログに掲載するなら、もっと記事を磨き上げる編集者がいるべきだと思う。これじゃ個人のブログ記事みたいで、マイクロソフトやアマゾンの同業者が出すものじゃないよ。俺にはこの問題をトラブルシューティングする技術力は全然ないけど、もし出版前にこの記事を1時間見せてもらえたら、半分の長さに、2倍のわかりやすさにして、技術的な詳細は一切損なわずに済むと思うな。

Cloudflareのブログは、エンジニアが個人的に書いたものを集めたものって感じだから、問題に取り組んだ人たちが書いた、ちょっと長くて興味深い文体のほうが好きだな。それを抑えちゃうと、効率は良くなるかもしれないけど、面白みが減っちゃうと思う。

絶対に編集者の手を入れるべきだったね。