ハクソク

世界を動かす技術を、日本語で。

Erlang/OTP 29.0

10日前原文(erlang.org)

概要

Erlang/OTP 29は多数の新機能と改善、不互換点を含むメジャーリリース セキュリティ強化や新しい言語機能、コンパイラ警告の追加 SSHやSSLなど主要コンポーネントのデフォルト設定変更 新しいガードBIFやネイティブレコードなど言語機能の拡張 詳細はREADME参照

Erlang/OTP 29の主な新機能と変更点

  • -unsafeアトリビュート による関数の危険性明示

    • 危険な関数呼び出しに対し デフォルトで警告 を出力
    • xref による危険関数や未ドキュメント関数の検出機能追加

  • SSHデーモン のデフォルト設定変更

    • shellおよびexecサービスが デフォルトで無効化
    • SFTPサブシステムも デフォルト無効化
    • 「 セキュアデフォルト」原則の実装

  • SSL のデフォルト暗号化方式変更

    • x25519mlkem768 （ポスト量子ハイブリッドアルゴリズム）が最優先に

  • io_ansiモジュール の追加

    • ANSIシーケンスによる ターミナル装飾やアプリ作成 が容易に

  • ct_doctestモジュール の新設

    • ドキュメント例の 自動テスト 実現

  • ignore_xrefアトリビュート の本体対応

    • ビルドツール依存から脱却 し、xref自身がフィルタリング

  • カレントディレクトリ のパス順序変更

    • デフォルトで「.」が 最後尾 に移動

  • Windows 32bit版 の廃止

言語機能の拡張

  • ネイティブレコード（EEP-79） の実装

    • タプルベースでない真のデータ型 として実験的導入

  • is_integer/3ガードBIF の追加

    • 値が整数かつ 範囲内か簡易判定 可能

  • 多値内包表記（EEP-78） のサポート

    • 例：[-I, I || I <- [1,2,3]]で複数値生成

  • compr_assign機能 による内包表記内の 変数束縛 が可能に

コンパイラ・JITの改善

  • compileモジュール のドキュメント強化

    • BEAM上で動作する言語実装者向け 推奨事項 追加

  • JITによる バイナリ処理の最適化

    • リトルエンディアン 複数セグメント処理の効率化

  • 定数値マップ内包表記 のコード生成効率化

    • 例：#{K => 42 || K <- List}

新しいコンパイラ警告

  • catch演算子 利用時の警告（非推奨）

    • try…catch推奨、警告無効化も可能

  • 部分式からの変数エクスポート 警告

    • 例：file:open(File, AllOpts = [write, {encoding,utf8}])

  • and/or演算子 利用警告（非推奨）

  • パターンマッチの書き方 警告

    • {a,B} = {X,Y}は{a=X,B=Y}推奨

  • 旧ガードテスト 利用時の警告

    • 例：list(L)ではなくis_list(L)推奨
    • Erlang/OTP 30で 旧ガード完全削除 予定

STDLIBの強化

  • rand:shuffle/1 および rand:shuffle_s/2 関数追加
    • リストのランダム並べ替え 機能

SSHのセキュリティ強化

  • デフォルト鍵交換アルゴリズム を mlkem768x25519-sha256 へ
    • 量子耐性と後方互換性 の両立

参考情報

  • 新機能や非互換点の詳細 はREADMEを参照

Hackerたちの意見

いい改善点がいくつかあるみたいだね。デフォルトでSSHデーモンを無効にするのはいいセキュリティの変更だし、SFTPもデフォルトで無効にするのは同じく良いと思う。io_ansiモジュールは結構面白そうだね。個人的には、Erlangで複雑なCLIアプリケーションを作るのはあまり得意じゃないと思うけど、あんまり試したことないからな。標準ライブラリにこれが入ると、将来的にいい感じになるんじゃないかな。ノード間でfwriteがシームレスに動くのはすごくいいし、Erlangから見て嬉しいポイントだよね。Native Recordsの追加も本当にクールだと思う。これがElixirでどう活用されるのか、ちょっと気になるな。今のところ、やってることによってレコード、タプル、マップが混在してる感じがするから。EEPが言ってるように、古いレコードが完全に廃止されることはないと思うけど、これはかなりの改善だね。

└

SSHデーモンは自動で有効化されたり、起動されたりすることはなかったと思うよ。二つのポイントは言い回しが違うけど、同じことを言ってると思う。SSHデーモンを起動する時、リストにある部分はデフォルトで起動しないってことだね。

SSHデーモンは、シェルとexecサービスのためにデフォルトで無効になっていて、「デフォルトで安全」という原則を実装しています。これにより、明示的に設定しない限り、認証されたユーザーが任意のErlangコードを実行することができなくなります。 SSHデーモンを起動する際、SFTPサブシステムはデフォルトで有効になっていません。

誰か中身を説明してくれない？

└

どの部分の中身？BEAM Bookが興味深いかもしれないよ。https://blog.stenmans.org/theBeamBook/

Erlang/OTPの「OTP」部分が何か気になる人のために説明すると、これは非常に信頼性が高く、障害耐性のあるアプリケーションを作成するためのライブラリと関連する原則のセットで、元々は通信分野のために標準化されたものだよ。「OTP Design Principles」の導入部分で基本的なアイデアの簡単な紹介をチェックする価値があるよ。https://www.erlang.org/doc/system/design_principles.html

└

OTP = Open Telecom Platform

レコードがエコシステムでどう活用されるのか、楽しみだな。

└

「え、何言ってるの、数十年も記録があるじゃん」って言おうとしたけど、チェンジログを読んだら面白いことが書いてあった。エリクサーがマップを「ネイティブレコード」にコンパイルする世界ってあるのかな？

-unsafe属性のサポートが追加されたね！Rustのリライトにちょうどいいタイミングだ！/s

誰か、WhatsAppがまだErlangを使ってるか知ってる？

└

そうだよ（ソース、今は彼らのために働いてる元同僚）。

└

直接の情報はないけど（2019年に辞めた）、WhatsAppの公開されているErlang関連のリポジトリはまだ活発だし、私の知る限りではErlangはMeta全体には広がってないから、もしWhatsAppが移行してたら、その後Erlangに取り組む意味はないよね。

└

彼らが2025年のCode BEAM Europeで講演したから、かなり可能性が高いと思うよ：https://www.youtube.com/watch?v=tC435RGwRCI

Erlangを使ってる人っているの？Railsを使って、その後Phoenixを試したけど、全然うまくいかなかった。Phoenixの盛り上がりが理解できない。ソロ開発者にとって、Railsは最も生産的なウェブアプリシステムだと思う。LLMはRuby on Railsのコードを書くのがすごく得意だし、Djangoを書くよりもずっと楽だった。Pythonのトレーニングコーパスは大きいけどね。実験的なアプリはRailsで書いて、安定したらGoに書き直す。Goで直接書かないのは、アプリのスコープが不明な時にトークンをたくさん消費するから。でもRailsにはすごく効率的。最近はReactやAngularは必要なくなって、RailsではHotwire、GoではHTMXを使ってる。Erlangのフォーラム自体もRailsで書かれたDiscourseを使ってるよ。

└

ErlangとElixirは違うけど、いい質問だね。WhatsAppはErlangを使ってると思うよ。

└

2016年からフルタイムでElixirアプリを書いてるけど、クライアントはクラッシュを見ないことにすごく満足してるよ。実際、過去10年間にプロダクションにデプロイしたアプリは100%の稼働率を誇ってる。（ハードウェア、OS、ネットワークの障害は除いてね）視野を広げた方がいいかも。

└

Railsは最初の1日くらいはPhoenixより速いと思うけど、その後は暗黙のロジックやメソッドが見つからない問題にぶつかるから、どう動くかを理解するのに時間がかかるよ。Elixir/Phoenixはその点で明示的だから、長期的なサポート（1週間を過ぎたあたりから）は楽になる。隠れた状態もないし、ModuleName.method(params)がどこから来てるのかを探す必要もないし、メソッドを呼び出すための設定もいらない（正しい引数を渡すだけでOK）。唯一の欠点は、使えるパッケージのライブラリが少ないことかな。

└

RubyのDiscordが何を使ってるか、予想してみる？

└

RailsとPhoenixの両方を使ったことがあるけど、ActiveRecordの方がPhoenixのORMよりも扱いやすいと思う。とはいえ、みんなが同じ感覚を持ってるわけじゃないけどね。組み込みの並行処理があるにもかかわらず、うちのチームはSidekiqのバージョンを作ることになった。スーパーバイザーがジョブ制御のすべてのユースケースをカバーしてないから。Capistranoでデプロイする方がElixirのビルドより好きだし、これは好みの問題だね。構造的パターンマッチングが唯一恋しい機能だけど、それは言語の機能だから仕方ない。LiveViewは使ったことがないから、その機能と比較はできないけど、JSON APIのバックエンドを持ってたから。

└

Phoenixは主にOTPとチャネル（あとはLiveViewかな、でも2026年には選ばないと思う）のおかげで面白いから、もしそれらが必要ないなら…Ectoも悪くないよ。Claude CodeはElixirを書くのがすごく上手い。驚きだけど、知ってることを使った方が生産性が上がるよ、LLMがあってもなくてもね。

29未満のプロダクションアプリは、できるだけ早くこれか最新のポイントバージョンにアップデートした方がいいよ。最近、プロダクションにアプリをデプロイしたら、自動セキュリティスキャンで2つのクリティカルなCVEと、2026年2月から5月にかけてのハイリスクなものが半ダース見つかった。

誰かまだErlangをグリーンフィールドプロジェクトで使ってる人いる？ここにはElixirのファンがたくさんいるけど、普通のErlangのことね。もしErlangを使ってるなら、Elixirよりも何が好きなの？