Elm 0.19.2、ビルド速度を改善
(elm-lang.org)- Elm 0.19.2 は、Elm 1.0 に向かう前に複数の小規模リリースでコンパイラ改善を反映していく流れの第一歩
- 大規模な Elm コードベースでのゼロからのコンパイルは 5.7秒、その後の増分ビルドは 350ms未満と測定され、開発中の集中の流れが途切れる可能性が減少
- 今回の改善は、パース中の割り当てを減らすことに重点が置かれ、85万行の実験で GC コピー量 20% 減少、最大メモリ使用量 10% 減少、全体速度 7% 向上が観測
- 実プロジェクトでのテストでは改善幅はさまざまで、351 モジュールをゼロからコンパイルする事例では 4.981秒から 2.595秒に短縮され、1.9倍高速化
- Acadia の作業から生まれた性能・言語アイデアが今後互換性を壊さないリリースとして順次反映され、最後の仕上げ後に Elm 1.0 へ進む計画
Elm 0.19.2 で高速化されたコンパイル
- Elm 0.19.2 は、蓄積されたコンパイラ改善を Elm に小さな単位で反映する最初のリリース
- 高速なコンパイラは、開発者がブラウザタブへ切り替えて集中を失う状況を減らす
- 増分コンパイルが 400ms未満なら、別の作業へ移る余地はほとんどなくなる
- 85万行の Elm コード基準の性能は次のとおり
- ゼロからのコンパイル: 5.7秒
- 増分ビルド: 350ms未満
- 実際の変更は、パース中の割り当てを減らす作業に集中
- GC コピー量 20% 減少
- 最大メモリ使用量 10% 減少
- 全体速度 7% 向上
- 50万行を超えるプログラムでは穏やかな改善が期待でき、より小さなプログラムでも Elm コンパイラは依然として非常に高速
- 実環境テストでは改善幅はプロジェクトごとに異なった
- 一部のプロジェクトでは小幅な改善
- 351 モジュールをゼロからコンパイルする場合は 4.981秒から 2.595秒に短縮され、1.9倍改善
- 新バージョンは Elm compiler 0.19.2 リリース から入手可能
Elm 1.0 へ向かう次のリリース群
- Acadia というデータベース関連のコンパイラ作業で得られたアイデアが、Elm にも活用される予定
- Acadia は現在非公開アルファ段階
- 公開共有は今年末を予定
- Elm に反映するアイデアには、性能改善と言語機能の両方が含まれる
- 例: より高速なパーサ
- 例:
equatable,hashable型
- こうした変化は Elm に自然に統合するため、互換性を壊さない小規模リリースのシリーズとして反映される予定
- 最後の仕上げ段階で Elm 1.0 へ進む計画
- Elm を初めて使うユーザーは オンライン例 と ガイド から始められる
- Elm 0.19.2 はパッチリリースのため、既存プロジェクトでも新バージョンをダウンロードしてすぐに利用可能
2件のコメント
Hacker Newsのコメント
最近のElmは、影響力の大きい研究用言語に近いものとして見ている
焦点ははっきりしているが、公開ロードマップや公式サポートはなく、リーダーシップはコミュニティやコアチームの構築にほとんど関心がなさそうに見える
それでも作業感は本当に良く、その結果として複数のフォークや派生プロジェクトが生まれた。最近のGleamカンファレンスでLouis Pilfoldが「Elmユーザーはそれぞれ自分のコンパイラを保守している」と冗談を言っていたが、実際に少なくとも6つはあり、先月にもさらに2つ発表された
Evanが1.0に向けて動いているのは喜ばしいし、Elmを「完成したもの」と呼んだうえで、後継プロジェクトの一つがフォークを統合し、コミュニティを育てるという難しい仕事を担えるといいと思う
個人的に次にElmに似たものを探すなら、Gleam + Lustreを見るつもりだ。コミュニティと設計を気にかけるメンテナーの組み合わせが良さそうで、フロントエンドとバックエンドの両方で動く
一時期は熱心に広められ、ブログ記事や発表も多く、熱気も導入もかなりあった
その後、作者が事実上姿を消し、プロジェクトは止まった
もちろん自分のプロジェクトなのでそうする権利はあるが、最初から期待値をもっと適切に設定すべきだったと思う。積極的な普及はアイデアの拡散には役立ったが、開発者たちに突然見捨てられたと感じさせることにもなった
二番目に良いところは、「コンパイルできれば動く」という哲学だ。正直、Rustの大部分でも似た感覚は得られる。Haskell感は薄いが、関数型の祖先たちの温かい影くらいはある
Elmは良い言語だが、Evanは本当に有用なものを作ることに関心がなさそうで、言語運営全般はめちゃくちゃだ
2023年に、なぜ今でもElmを使っているのかについて記事を書いた
https://taylor.town/elm-2023
2026年の今でも、同じ理由でElmを使い続けている :)
おまけに、ClaudeはElmとかなり相性が良いように思う
https://taylor.town/diggit-000
約2年前、大好きな言語であるElmでブラウザ向けのSnakeゲームをChatGPTによるバイブコーディングで作ってみる実験をした
当時はかなり粗く、大規模言語モデルがElmを終わらせるかもしれないと結論づけた
今はElmをプロダクションで使っており、大規模言語モデルはずっと良くなった。むしろElmは今の大規模言語モデルに理想的な言語なので、導入を増やす可能性もあると思う。多くの言語より単純で安定しており、言語の中に強い意見を持つアーキテクチャが組み込まれているため、コードベース同士が非常によく似るからだ
Rustでもより多く作るようになり、Rustのドキュメントもより読むようになっている。大規模言語モデルは、それを使う対象そのものを学ばないための言い訳であってはならず、そういう姿勢なら悪いエンジニアだ
大規模言語モデルは、受け取った結果を保守できるように調査し学ぶ時間を稼いでくれる。問題を理解していれば、プロンプトもよりうまく書ける
結局は学習データとRLHFにElmがどれだけ含まれているかに依存する。構造化されたフレームワークや言語はコードベースがより似通うため、生成しやすくなるという点には同意する
しかしそれだけでは不十分で、通常、開発者の導入はそれ自体がはるかに複雑な議論だ
Pythonは非常にうまく扱うので奇妙に感じたし、Elmは現代の言語の中でも最も安定している部類だ。あまりに安定しているので、変わらないと文句を言われるほどだ。ただ、最後に試したのは1年ほど前なので、今は良くなっているだろうと思う
JavaScript関連の制限は解決されたのだろうか？ 記憶では、JavaScriptと連携するにはElmのPortsメカニズムを使う必要があり、直接ラッパーを書けないようにしていたと思う
誰かが直接JavaScriptラッパーやFFIを書けるようにフォークして、議論になったこともあった気がする
これは意図的な選択で、1.0まではもちろん、その後も維持される可能性が高い
このプロジェクトがまだ生きているとは思わなかった。皮肉を言うつもりではないけれど、もう終わったものだと思っていた
だから死んでいたし、今ようやく復活したということだと思う。その間にコミュニティはかなりしぼんでしまったはず
非常に人気のある機能だったのに、言語の創始者が嫌っているという理由で、コミュニティが強く維持を求めたにもかかわらず削除された
技術的にはおそらく正しい判断だったのだろうが、社会的には非常に不人気で、おそらく誤った判断だったと思う
入社前は知らなかったが、ReactやReduxなどの経験があったので素早く習得できた
Elmコミュニティなら、これを機能と呼ぶだろう。6〜8年前に書かれたReactコードのうち、現在のReactツールチェーンで完全に同じようにうまく動くものがどれだけあるだろうか？
価値観がまったく違う。2026年の良いReactコードは、2016年以降コンパイルできているElmコードに似て見える
Elmはチュートリアル以外では使ったことがないが、最近はGleamのフルスタックアプリを作り、その大半でコーディングエージェントを活用した。初期にはコード構造をかなり厳密に管理したが、そのやり方はかなり相性が良かった
Elm 1.0よりも、Elm 0.19以降のほうが気になる。0.19はElmの作者が公式に承認していないすべてのネイティブモジュールをブロックしたバージョンで、私にはそれが事実上Elmの終わりを示したように見えた
1.0へ向かう発表として、これより悪いものはなかなか思いつかない。誰が気にするのか？ ローカライズやアクセシビリティ対応がないなら、UIフレームワークをプロダクション準備完了の1.0と呼ぶのは筋が通らない
サードパーティの貢献者がブラウザAPIをつなげられる範囲を制限したことが、玩具プロジェクト以外でのElmの勢いを殺したのだと思う
今ではプロダクション向けというより、Evanがコンパイラのアイデアで遊ぶためのサンドボックスのように見える
ローカライズは、言語ごとに大きなレコードを1つ用意し、文字列を使うアプリの各部分に渡す方法で処理している。複数形や言語固有の特殊なケースには、レコード内に単純な関数を入れられるので非常に便利だ
アクセシビリティは、良いHTML、ports、そして自動補完のtypeaheadのような複雑なケースではWeb Componentsを組み合わせることで実現している
他方で、7年間何もなかったあとに小さなコンパイラ性能改善を1つ出して「1.0への道」と呼ぶのは、少しどうかと思う。悪意はないが、なぜわざわざ？ もう死んでいて、喪も終わっていて、みんなとっくに去っている
本当に驚くようなリリースが出るまでは、多くの人は気にしないと思う
Evanは何かを指しているのに、みんな指ばかり見ているように思う。これは実のところElm自体ではなく、Acadiaの準備に関することだと思う
彼の発表 Economics of Programming Languages https://www.youtube.com/watch?v=XZ3w_jec1v8で、この7年間取り組んできたものを少し公開している。関数型のアイデアを適用したクエリ言語だ
彼はWebアプリで型情報が通常壊れる境界を指摘している。言語とストレージの間、ストレージと転送の間だ
これらの境界を越えて型情報を保てるなら、何が得られるのか？ 彼が挙げた答えの1つは、より簡単なマイグレーションだ。手でSQLを書く代わりに、型の差分で処理できる
だから正しい問いは、Elmに入る変更を見てAcadiaがどんな姿になるか推測できるか、だと思う。インクリメンタルコンパイルはクエリ言語に何をもたらすのだろうか？
アイデアがどれほど良くても、Arcadiaにより未来志向でコミュニティ中心の開発モデルがなければ誰も採用しないだろう。せいぜい「XYZにインスピレーションを与えたプロジェクト」になるだけだ
Evanはこれが次の巨大な何かだと考えているかもしれないし、実際にそうかもしれないが、Elm後の世界が十分に耳を傾けるかは分からない
特定の言語機能をElmチームだけが使えるようにしていた件は撤回されたのだろうか？ あれは言語を殺しかねない判断に見えた
Elmはかなり勢いを失ったと見てよいのだろうか？ もうHNでもほとんど議論されておらず、リリースやニュースの間隔が大きい理由の1つなのか気になる
リリース間隔を見ると、0.19.2 “Faster builds, and the Road to Elm 1.0”は2026年7月で、0.19.1 “Friendly syntax hints, faster builds”は2019年10月だ
Lobste.rs のコメント
わあ！ Elm 0.19.1 が出たのは2019年10月21日なので、もう7年前で、それが Elm 開発に関する最後の公開ニュースでもありました
プロジェクトの新しいニュースを見られてかなりうれしいです
サイドプロジェクトで Elm を使ってみたときは本当に楽しかったのですが、外から見るとコミュニティは少し静かに見えていました。とても期待できるニュースです
Elm は Web 開発を楽しいものにしてくれました
1.0 が何をもたらすのか楽しみです
本当にうれしいサプライズです
Elm の 安定性はずっと気に入っていましたし、1.0 も過激な変更はしないように見えるので、個人的には良い方向だと思います
==などがもはや任意の型を受け付けなくなるなら、変更しなければならない Elm コードはかなり多いはずです。アップグレード手順がどうなるのか気になりますElm のアップデートを見られてうれしいです
プログラミング言語が何年もまったくアップデートされないのは少し異例です。理由は理解できますが、世間の認識というものには不思議な面があります
このニュースは良いですね
ときどき、現代フロントエンド開発の狂気から離れる良い休憩のように Elm をまた眺めたりしています
ZuriHac 2026 で Evan の発表を見る機会があり、新しい Elm リリースが来るとほのめかしていて本当に驚きました
動画が近いうちに上がることを願っていますが、安定性を目指すやり方が、この業界の速い進歩への強迫観念とは相性が良くないことを理解していたようでした。私の理解では、Elm はもっと小さく速いステップを踏む可能性もあります。楽しみですし、その発表のおかげで Elm がとても恋しくなりました
equatableやhashable型のような、より目立つ機能を Elm がどう扱うのか気になりますこの言語の議論を呼ぶ設計上の選択の一つは、型クラスのような、より強力な Haskell 風の型システム機能を避けている点です。個人的には、自然で明確に定義された順序を持つカスタム型でさえ辞書のキーとして使えないことが、ずっと不便でした。それでも Elm の作業が続いているというのは、全体として良いニュースです
ブログ記事の表現から推測すると、既存の制約付き型変数、つまり
number、appendable、comparable、compappendに加えて、新しい 制約付き型変数をいくつか追加する程度なのではないかと想像しています