Elixir 1.17 リリース: パターンの集合論的型、Duration、OTP 27
(elixir-lang.org)- 段階的な集合論的型がパターンから型を推論してコンパイル時警告を出し、既存ソフトウェアの変更なしにコードベースの欠陥やバグを見つける機能を追加
- 新しい型警告は現在 atom と map/struct に焦点を当てており、存在しないキーへのパターンマッチ・フィールドアクセス、モジュールでない関数呼び出し、誤った無名関数呼び出し、struct 間の構造的比較、重ならない型同士の比較、誤った binary パターン、未定義の例外 rescue などを検出
- 型チェッカーは現在、同じ関数内のパターンでのみ型を推論し、guard や関数境界をまたぐ解析は今後のリリースで追加予定
- Erlang/OTP 27 のサポートが追加され、Erlang/OTP 24 のサポートは終了。Windows を含め、Erlang/OTP 26 以上への移行を推奨
- Windows 向け Erlang ターミナルグラフィカルインターフェース WERL のサポートは Elixir v1.18 で削除予定
- 新しい
Durationデータ型とDate.shift/2が追加され、日付、時刻、date time を duration に基づいて移動でき、DateTimeではタイムゾーン変更と Daylight Saving Time を処理 Kernel.to_timeout/1が追加され、duration と integer をProcess、GenServerなど複数 API で使う timeout 値に正規化- Erlang/OTP 27 の process label 機能を Elixir で
Process.set_label/1として利用でき、Logger はgen_statemレポートを整形し、logger イベントに Erlang/OTP 27 の process label を含める Keyword.intersect/2,3、新しい Mix profiler のmix profile.tprof、%{}が struct にもマッチしてしまう落とし穴を減らすための guardKernel.is_non_struct_map/1を追加mix profile.tprofの追加に伴い、mix profile.cprofとmix profile.eprofは soft-deprecation の対象に
1件のコメント
Hacker Newsの意見
ここ数年で、Elixirエコシステムは本当に多くの用途において最もシンプルな解決策になりつつある
PhoenixとLiveViewでWeb開発は速くて楽しく、NX/Axon/Bumblebeeで人工知能、Membraneで音声・動画ストリーミングと処理、CommandedでCQRSとイベントソーシング、Nervesで組み込み機器開発、開発中のLiveView Nativeではモバイルアプリまで可能になる
キュー、パイプライン、一括処理も基本機能で対応できるし、GenStage、Broadway、Obanを使って用途に応じた処理もできる
それでも個人的には中核機能はElixirのREPLであるIExだと思う。開発中でも運用中でもコードと直接やり取りし、内部を調べ、デバッグできるのは人生が変わるレベルだ
そこに型が加わるのは、私たちがデプロイするコードへの確信をさらに強くしてくれる最後のパズルの1ピースだ
EctoはSQLデータベースを関数型のやり方で扱えるようにしてくれる。ORMをどう捉えるべきかはいまだによく分からないが、合成可能なクエリをいくつか使うだけでSQLの90%を消せたので成功だと思う
デプロイ、稼働時間、セグメンテーション違反、パッケージ処理時間などで数か月苦労した末に、Webサーバーとデータ層をElixir + Phoenixへ移し、今でははるかによくテストでき、推論しやすく、スケーラビリティも信頼でき、デプロイも簡単になった
設定より規約のおかげでPhoenixでは信じられないほど速く始められ、FastAPIよりずっと速かった。数か月前にやっておくべきだったと思う
今はNxでモデルを学習させ、Bumblebee/Livebookも触りながら、アプリにpresenceやlive機能をほとんど無料同然で追加している
どれもLiveViewの概念、性能、開発のしやすさをそのまま使える
ErlangやElixirのような環境にはもう戻るのは難しい気がする
他の言語でコードを書くたびに、とくに仕事でコードを書くたびに本当に恋しくなる
良いREPLがあると、プログラミングでよくぶつかる摩擦が大きく減る。アプリ全体を動かして問題のあるコード片をつつく代わりに、アイデアを少しずつ積み上げ、その場で試せる
Elixir標準ライブラリも素晴らしく、REPLからドキュメントにアクセスするのもとても簡単なので、流れを保つのに非常に役立つ。Elixirでコーディングしていると、小さな疑問を調べるためにブラウザを開くことはまれで、たいていはREPLを離れずに答えを見つけられるからだ
そのため自分のコードにも良いドキュメンテーション文字列を書くよう促される
さらに良いのは、実行中のコードと一緒にREPLを動かせることだ。アプリを動かす必要があるときでもそのまま実行しながら、開発環境ではライブデータを操作し、内部状態を調べられる。他のスタックでは不可能だったり、デバッガが必要だったりすることだ
ここに型関連機能まで入ってくれば、ツールはさらに良くなると期待している
しかも関数型パラダイムの楽しさと力があり、可変性や状態を扱う堅牢な方法もあり、LISP構文を我慢する必要もない。個人的にはあらゆる音程が合う言語で、本当に気に入っている
IExはIRBにない何かをしてくれるのか？
この数年間、ElixirとErlangのチームは本当に素晴らしい仕事をしてきたし、ライブラリ作者や書籍著者たちの仕事も見逃せない
これほどリリースが楽しみだったことはない。しばらくElixirとOTPのコミットを追っていたが、Elixir/Erlangには確かな勢いがついていると感じる
サイドプロジェクトのバックエンドに Elixir を使っていて、フロントエンドは Remix だが、バックエンド作業はとても快適で生産的。
LiveView の生産性は認めるが、自分の場合は不安定なネットワーク接続を扱う必要があるため、案の定 LiveView の体験は良くなかった。
開発者の頭の中で Elixir が LiveView とある程度切り離されるといいと思う。LiveView やリアルタイムチャネルなしで単純な API バックエンドとして使うだけでも、Elixir は本当に楽しい
ただ、LiveView はどうにも苦手。理解するのがかなり難しく、足元の落とし穴も多い。たとえば認証チェックをルーターの
pipe_throughと LiveView のon_mountコールバックの両方で忘れずに処理しなければならないことがある。[0] を参照Phoenix と LiveView を初めて触る開発者にとって、上の文が何の意味もなさないという事実だけでも、LiveView がデフォルト方式であるべきではない証拠として十分だ。
必要のないところに非常に急な学習曲線を作ってしまう。Elixir/Phoenix 自体は簡単。
新しく Elixir/Phoenix を学ぶ開発者なら、まず MVC スタイルの Phoenix dead views を使い、その次に OTP の基本を学ぶために『Elixir in Action』を読む順番がよいと思う。この本はやさしくて目が開かれる内容で、ほとんどすべてのコーディングのやり方を変えてくれた。
そしてその後でようやく LiveView に進むのがよい。
[0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
mix phx.newを—no-liveフラグ付きで実行すれば、LiveView なしで Phoenix を使える。既存プロジェクトでも手動で取り除ける問題は技術知識やインストール時のデフォルト設定ではなく、開発者の認識の問題だ。あまりにも多くの人が Elixir とその周辺エコシステムを LiveView から連想し、それ以外のエコシステムを無視したまま通り過ぎてしまう。
Elixir にはそれ以上のものがあり、Phoenix でさえ LiveView よりずっと大きい。
LiveView はもちろん、Phoenix すら使わなくても、生産的でコスト効率の高い Elixir アプリケーション は十分に作れる。バックエンドで Elixir を選ぶことが今よりもっと一般的になるべきだが、別の選択をさせてしまう通念や不安があることも理解はできる
自分のスタートアップを Elixir 100% フルスタック で作っているが、これまで使った技術の中で最高。
本気の技術仲間たちに、どれほど良いかをずっと布教している。
あとは RabbitMQ とそのクライアントが OTP 27 で動いてくれれば本当にうれしい。アップグレードしたい
こちらでは SSL 証明書によるクライアントログイン方式を何年も使っていて、安定性にはとても満足している
Elixir と Phoenix については、いくら褒めても褒め足りない。そこに型まで来ればさらに良くなるはず。
BEAM とその強力さについてはよく耳にするだろうが、経験上、スタックのその部分を意識しなければならない段階に来るまでには本当に長く持ちこたえられる。Phoenix がその部分を見事に抽象化してくれるので、努力せずに利点を得られる。
たとえば Oban がある。Postgres の中で Elixir コードにより、強力で柔軟で使いやすいバックグラウンドジョブをほとんど無料同然で手に入れられる。本当にすごい。
一度使ってみることを勧める
LiveView とその周辺のマーケティング偏重のせいで、本来ならもっと長く OTP を知らなくても済んだはずの人たちが、旅のごく早い段階、もしかすると最初のコントローラールートの時点で OTP に直面することになる。
堅牢な LiveView フローを書いて適切にテストすることは、複数の非線形フローやさまざまな call/cast の入り口を持つ stateful な GenServer を書くのと同じくらい知的に複雑だ。
LiveView は別の用語を使い、async assigns のような小さな利便レイヤーもあるが、機械的には文字どおり GenServer。効果的に使うには、この点をしっかり理解することが重要だと思う。
Oban は本当に気に入っていて、他のエコシステムでは深く恋しく感じる
余談だが、elixir-desktop [1] を使ったことがある人はいるだろうか？ wxWidgets + LiveView の組み合わせで、Electron アプリにかなり近い。
[2] では Wojtek Mach が Elixir チームが Livebook Desktop をどう作ったかを説明している。プロジェクトがどう始まったか、macOS 向けアプリを作る中で見つかった微妙なバグ、Windows での wxWidgets の限界、さまざまな実装の詳細を扱っている。
Elixir チームが Livebook ベースで elixir-desktop のようなものを公式リリースしてくれるといいと思う。つまり Livebook リポジトリをフォークして、LiveView ベースのデスクトップアプリケーションを生成する公式テンプレートプロジェクトを提供するような形だ。
今の Livebook は Windows と Mac 向けの実行ファイルとして配布されている。Electron のように、開発者がスタンドアロン実行ファイルを配布できるように同じアプローチを取るのはどうだろうか？
LiveView Native [3] も知っているが、方向性は違うと思う。
[1] https://github.com/elixir-desktop/desktop-example-app
[2] https://www.youtube.com/watch?v=Kiw6eWKcQbg
[3] https://native.live/
Elixir の普及を妨げてきた 型がない という言い訳が消える日を楽しみにしている
10年間ここで素晴らしい Elixir の話を読んできたし、この言語も好きです。
でも、Elixirの仕事探しは数年前に諦めました。主流言語より給与がずっと低く見えたからです。
一番使いたい言語かもしれませんが、私にとっては技術スタックより給与と優れた製品のほうが重要なので、実際には使えないかもしれません。それでも遠くから見守るのは相変わらず楽しいです。
アメリカで探しているのか、別の地域なのか気になります。
今回のリリースの良い機能は、構造体と一緒に動作する
get_in/1の追加です。たとえばget_in(struct.foo.bar)のように使えます。fooがnilを返しても、barへのアクセスで例外は発生しません。通常のマップではない階層では、次のように
Access.keyが必要でした。get_in(struct, [Access.key(:foo), :bar])これが私の望んでいた最後のピースです。この先の段階にも期待しています。
それ以外では、私の基準ではこの言語は機能的に100%完成しています。
今でもそうなのでしょうか、それとももうErlangまで降りる必要はないのでしょうか？