その言及された事件についても気になるんだけど、ポストモーテムのリンク誰か持ってない？ネットで探しても見つからなかった。

確かに小さいように見えるけど、BEAMはマイクロ秒（μs）単位の応答時間が多いからね。それに慣れてると、何かがミリ秒に「吹き出す」とアラームが鳴るのもわかる気がする。

これ、BEAMシステムでは簡単に起こりうるよ。共有状態にアクセスしたいとするじゃん？それを守るためにgen_serverを作るんだ。gen_serverは基本的に巨大なミューテックスみたいなもん。gen_serverは普通のBEAMプロセスで、メッセージキューに送られたリクエストを処理して、返信メッセージを返す。例えば、通常20μsでリクエストを処理できるとする。そうすると、15msの遅延で750件のメッセージがメッセージキューに溜まることになる。これだけじゃ大規模な障害を引き起こすには足りないかもしれないけど、処理の過程でメッセージキューを安全じゃない方法で使ってると、問題が起こるかも。メッセージをチェックするとき、BEAMはメッセージキュー全体を検索するからね。BEAMが最適化できるパターンもあるけど（ほとんどのパターンは安全じゃないと思うし、BEAMはgen rpcスタイルのメッセージパターンだけを最適化してる）、安全じゃないパターンを使ってメッセージキューが溜まってると、システムのスループットが壊滅的になる。メッセージ処理にかかる時間はメッセージキューの長さに依存するから、メッセージ処理にかかる時間がメッセージキューの長さに影響する。しかも、gen_serverのコードに明示的なreceive文がない場合もある。ライブラリを使ってるだけで、どこかで大きなメッセージキューに対して安全じゃないreceiveを使ってると、痛い目に遭うことも。BEAMは代替のメッセージキューも追加したから、プロセスのメインメッセージキューの代わりに使えるはずだけど、まだ多くのライブラリはこれを使ってないと思う。この代替は「エイリアス」（https://www.erlang.org/doc/system/ref_man_processes.html#pro...）で、思ってたのとは少し違って、「失われた」メッセージからキューを守るためのもの。エイリアスがないと、「タイムアウト」が原因でプロセスメッセージキューが待たれていないメッセージで汚染されることがある。これが大きなメッセージキューによるスループットの低下につながることも。ただ、通常、長生きするプロセスはキュー内のメッセージを処理するループを持ってる。

本当に制約のあるデバイス向けには、AtomVMっていう別の実装があるよ。他のエコシステムでBEAMやOTPみたいなものを実装しようとしたけど、無駄になった努力がたくさんあるんだ。たいていはVMじゃないけどね。

BEAMが1990年代後半に発明された頃、2000年代初頭にはかなりユニークな提案だったんだ。今では、BEAMが特有にやってることはほとんどないよ。それが他にない理由かもね。市販のコンパイル言語は、今のBEAMと同じ問題を解決できるし、他の利点もあることが多い。Erlangコミュニティには、BEAMと同じ方法で解決できないなら、必然的にBEAMより劣るって考える人がいるけど、それは間違いだよ。「違う方法でも同じ問題を解決できるか？」って聞けば、2025年には選択肢がたくさんあるけど、2000年の選択肢はずっと弱かったからね。確かに、BEAM互換性を持つのは見た目以上に難しいよ。https://github.com/ergo-services/ergoみたいなプロジェクトができるし、他の言語でもあると思う。ただ、個人的にはかなりニッチなニーズだと思う。既存のBEAMインフラに接続する必要がなければ、グリーンフィールドプロジェクトにはあまり良い解決策とは思わない。もっと現代的なツールや、選んだ開発環境によりネイティブなソリューションの方がいいよ。

現実的には、現代のKubernetesインフラはBEAMに似てるよ。少なくとも提供する機能はね。今の時代、高度にスケーラブルで自己修復するシステムをデプロイする一般的な方法だよ。それに、k8sを使えば特定の言語に縛られないし（Erlang/Elixir以外にもいくつかあるけど、人気はないね）、限られた開発者リソースや興味に悩まされることもないんだ。

一番広く使われてるのは多分Goだと思う。BEAMは「Erlangライクな言語」に合わせて作られてるし（逆かもしれないけど）。Elixirを書くと、動作の基本的な意味論のおかげでErlangにすごく似てる感じがする。Gleamも型を超えればErlangに近いしね。Goもgoroutinesやグリーンスレッド、Erlangみたいなプロセスを並列処理の基本的な要素にしてるけど、OTPが持つ同時実行アプリケーションの構造に関する「意見」は持ってないんだよね。

それは…バカじゃない？

出版社に依存する必要があるの？独立して本を書けないの？それとも出版社の「ブランド」やその他の特典があるから？

3冊の本を書いた経験から言うと、自己出版するか、出版社が求める本を書くかのどちらかだね。特定のタイプの本を専門にしている出版社を選ぶことも大事だよ。ある出版社は「Pythonで21分でAIを学ぶ」みたいな本を求めてるし、他の出版社は「Javaクラスローダーの深い暗い秘密」を求めてる。O'Reillyはニッチな技術系の本には最高だよ。業界のほとんどは初心者向けの本を求めてるから、そっちの方がボリュームがあるんだ。幸い、自己出版は今まで以上に簡単になってるし、いろんなサイトでオンラインでコピーを売るのも簡単だから、必ずしも無料で配る必要はないよ。でも、魔法の公式はないからね。本当にニッチなものを書きたいなら、出版社が興味を持つとは期待しない方がいいよ。自己出版して、自分で宣伝する覚悟が必要だね。

ちょっと自己宣伝になるけど、これがきっかけでクライミングのための筋力トレーニングに関する本を書いたんだ。いろんな穴に飛び込んでいった結果だよ。自己出版する準備はしてたけど、興味を持ってくれる出版社が見つかったんだ。読みやすくするためにいくつか変更しなきゃいけなかったけど、自分で出版社にアプローチしてみるのもいいかもしれないよ。

面白いことを言えれば、みんな理解する方法を見つけると思うよ。キャリアの初めに、ドン・ボックスの「Essential .Net」に出会ったことを覚えてるけど、彼は特にターゲットにしてるオーディエンスがいたわけじゃないと思う。彼はCommon Language Runtime (CLR) の裏側をそのまま見せてくれたんだ。実際に「essential .net」を理解するのには何度も読み返さなきゃいけなかったよ。

Elixirはかなり素晴らしい代替手段だよ。

Erlangは、他の言語でもより良いプログラマーにしてくれる言語の一つだよ。

みんな一番いい人材を雇おうとしてるけど、結局は一番低いレベルに合わせちゃうんだよね。「でも、数週間で新しい言語を学べないエンジニアを雇ったらどうするの？」みたいな感じで、ずっとその繰り返し。

これは純粋にマーケティングの問題だと思う。他の言語（Java、C#、Go）は大企業のバックアップがあって、成功させるために利害関係があるからね。Erlangの企業オーナーは、最初からそれを潰そうとしてたし、それ以降も技術リソース以外にはあまり関心を示してこなかった。Elixirみたいなものが出てくるまでは、あんまりマーケティング的な素材は見られなかったし、あれもRubyモデルに近いから、開発者向けなんだよね。2014年にElixirが登場した世界は、2004年にRailsが出た時とは全然違うし。開発者はBEAM言語の良さを納得させられることが多いけど、華やかさがないとMBAの人たちを納得させるのは難しいよ。

投資のギャップって感じかな。RustやGo、Pythonなんかは、静的解析や型チェック、開発者の使いやすさにたくさん投資してくれる大きな支援者がいるけど、Erlangのエコシステムは必ずしも同じような愛情を受けてるわけじゃないんだ。主要なユーザーたちは、だいたいBEAMの外で何かを作ったり、方向転換したりしてるね。