Erlang/OTP 29.0

 (erlang.org)
1 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • SSHデーモン はデフォルトで shell と exec サービスを無効化し、明示的に設定しない限り、認証済みユーザーが任意の Erlang コードを実行できないようになった
  • SSHデーモン起動時に SFTPサブシステム もデフォルトでは有効化されなくなり、セキュリティのデフォルト設定が強化された
  • -unsafe 属性が追加され、安全でない関数を示せるようになり、コンパイラは Erlang/OTP で常に安全でないと分かっている関数呼び出しに対してデフォルトで警告を出す
  • xref は安全でない関数呼び出しとドキュメントのない関数を検出でき、ignore_xref 属性のフィルタリングも xref 自体で処理するように変更された
  • SSL のデフォルト設定では x25519mlkem768 が最優先の鍵交換グループになり、SSH のデフォルト鍵交換アルゴリズムも ML-KEM-768 と X25519 を組み合わせた mlkem768x25519-sha256 に変更された
  • Erlang システムのデフォルトコードパスで、現在の作業ディレクトリ . の位置が先頭から末尾へ移動し、読み込み順序が変わった
  • Windows 向け 32-bit Erlang/OTP ビルド は今後提供されない
  • EEP-79 の native records が実装され、Erlang/OTP 29 では実験的機能と見なされる
  • is_integer/3 guard BIF、EEP 78 に基づく複数値 comprehension、compr_assign 機能による comprehension 内での変数バインディングが追加された
  • コンパイラは catch、部分式の外への変数エクスポート、and/or、{a,B} = {X,Y} のような match alias パターンに対してデフォルト警告を追加し、それぞれに無効化オプションを提供する
  • 古い guard test は Erlang/OTP 30 で言語から削除される予定で、従来の obsolete guard 使用警告も引き続き適用される
  • io_ansi によりターミナルへ ANSI/Virtual Terminal Sequence を出力でき、ct_doctest により Erlang モジュール文書とドキュメントファイルの例をテストできる

関連記事

1件のコメント

 
GN⁺ 5 시간 전
Hacker Newsのコメント

  • 改善はかなり良さそう。SSHデーモンをデフォルトで無効化し、SFTPもデフォルト無効にしたのは、セキュリティ面で良い変更だと思う
    io_ansi モジュールもかなり良さそう。今のErlangは複雑なコマンドラインアプリケーションを作る際の選択肢としてそこまで語られることは多くないが、標準ライブラリに入れば今後大きな助けになりそう。fwrite がノード間で自然に動作する仕組みも、Erlangに期待するまさにその強みだ
    Native Records の追加も興味深い。今のElixirでは状況に応じてレコード、タプル、マップが混在して使われている感じなので、今後どう活用されるのか気になる。EEPで述べられているように既存のレコードが完全に廃止されるわけではないだろうが、かなりの改善に見える
    https://www.erlang.org/doc/apps/ssh/ssh.html
    https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html
    https://github.com/erlang/eep/pull/81

    • SSHデーモンが自動で有効化または起動されたことはなかったと思う。両方の項目は表現こそ違うが、意味としてはSSHデーモン起動時に列挙された構成要素がデフォルトでは起動しないということのようだ
      SSHデーモンは今やシェルとexecサービスがデフォルトで無効化されており、secure by default の原則に従っている。明示的に設定しない限り、認証済みユーザーが任意のErlangコードを実行できないようにしている
      SFTPサブシステムも、SSHデーモン起動時にデフォルトで有効化されなくなった

  • Erlang/OTPの OTP が何か気になっている人向けに説明すると、もともとは通信分野向けに高信頼・耐障害性アプリケーションを標準化して構築するためのライブラリと原則のまとまりだ
    基本的な考え方としては「OTP Design Principles」の導入部を軽く読むとよい
    https://www.erlang.org/doc/system/design_principles.html

    • OTP = Open Telecom Platform

  • プロダクションアプリが29未満なら、このバージョンか最新のパッチ版にできるだけ早く更新したほうがよいかもしれない。さっき本番にデプロイしたところ、自動セキュリティスキャンで2026年2〜5月日付の CRITICAL CVE 2件 と、HIGHリスクの項目がいくつも検出された

    • リストはある？

  • まだ新規プロジェクトで Erlang を使っている人がいるのか気になる
    ここにElixir好きが多いのは分かっているけど、純粋なErlangの話
    まだErlangを使っているなら、Elixirより好む理由が何なのか知りたい

    • 今年だけでもある。AtomVMベースの新しいIoT案件、Erlangで書いたアプリケーションサーバー、そしてまだ作業中のTUIフレームワークがある
      Elixirは自分にとってErlangに対する実質的な利点を与えてくれない。もちろん利点はあるのだろうけど、Erlangのほうが自分の思考にしっくりくる。学んだり助けを得たりする場も、もっと社交的な集まりのように楽しみたいのだが、自分に合う場所をうまく見つけられていない

  • 内部構造を誰か説明できる？

  • レコードがエコシステムの中でどう位置づけられるのか気になる

    • 「レコードは何十年も前からあったのに？」と言おうとして、変更ログを読んでみた
      興味深い。Elixirがいつかマップを native records にコンパイルする世界があるのか気になる

  • WhatsAppはまだErlangベースなのか知っている人いる？

    • そうだよ
      2010年代初頭からErlangを使っていて、その頃に技術業界では、WhatsAppがエンジニア30人ほどで4億人超のアクティブユーザーを支えていることが知られるようになった
      当時そこのエンジニアの1人に連絡し、アメリカに住んでいた頃にメールでいくつかの質問に丁寧に答えてもらった。結局コーヒーも飲んだし、今でも連絡を取り合っている
      Erlangは今でもWhatsAppの重要な一部だと言ってよいと思う
    • Code BEAM Europe 2025で発表していた内容を見る限り、まだその可能性はかなり高い: https://www.youtube.com/watch?v=tC435RGwRCI
    • 自分で直接知っているわけではないけど、2019年に離れたし、WhatsAppの公開Erlang関連リポジトリは今でも活発。知る限りErlangがMeta全体に広がったわけでもないので、もしWhatsAppがErlangから離れていたなら、その後もErlang開発を続ける理由はあまりない
    • そう。以前の自分の部下が今そこで働いている
    • そう。Erlang を使っていて、Rust も徐々に増えてきている

  • -unsafe 属性のサポート追加とは、Rustに書き直すには絶好のタイミングだな /s

  • Erlangなんて一体誰が使っているのか分からない。Railsを使ってからPhoenixを触ってみたけど、何かをやり遂げるのがずっと難しかった
    Phoenixへの熱狂が理解できない
    1人開発者にとっては、Railsがたぶん最も生産的なWebアプリシステムだ。LLMもRuby on Railsのコードはとても上手に書く。Pythonの学習コーパスは膨大なのに、私の経験ではDjangoよりずっと上手い
    実験的なアプリはRailsで書いて、安定したらGoで書き直す。アプリのスコープが曖昧なときに最初からGoで書くとトークンをずっと多く使うが、Railsには非常に効率的だ
    最近はReactやAngularももう不要で、RailsではHotwireを使い、GoではHTMXを使っている
    Erlangフォーラム自体もRailsで書かれたDiscourseを使っている

    • 2016年からElixirアプリをフルタイムで書いてきた。クライアントはクラッシュを見なくて済むことにとても満足している。実際、この10年で本番にデプロイしたすべてのアプリケーションは100%の稼働率を記録している。自分では制御できないハードウェア、OS、ネットワーク障害は別として
      もう少し視野を広げたほうがいい
    • RailsがPhoenixより速いのは、開発速度という意味ではせいぜい初日くらいまでだと思う。その後は 暗黙のロジック や method_missing のようなものに突き当たり、動作を把握するのに余計な時間がかかる
      Elixir/Phoenixはその点でより明示的なので、長期保守、つまり最初の1週間を過ぎたあたりからはずっと楽になる。隠れた状態もないし、ModuleName.method(params) がどこから来たのか探し回る必要もないし、そのメソッドを実行するために何かを設定する必要もなく、正しい引数を渡せばよい。欠点は、すぐ使えるパッケージライブラリがやや少ないことくらいだ
    • Ruby Discordが何を使っているか当ててみる？
    • Phoenixが主に面白いのは OTP とチャネル、それにLiveViewがあるからだと思う。ただ、LiveViewは2026年に自分が選ぶ選択肢ではなさそうだし、そういう機能が必要ないなら魅力は薄いかもしれない
      Ectoも悪くない
      Claude CodeはElixirコードをかなり上手に書く
      驚くことに、LLMがあってもなくても、もともと知っている技術を使うときのほうが生産的だ
    • 「アプリのスコープが曖昧なときに最初からGoで書くとトークンをずっと多く使うが、Railsには非常に効率的」と書いていること自体が絶妙な皮肉だ。これだけ長々と語っておきながら、結局コードを書いているのは本人ではないと明かしてしまっている