DEV Community

voluntas
voluntas

Posted on

私的な 2015 年 Erlang/OTP 振り返り

Erlang/OTP 18 系のリリース

Erlang Programming Language Erlang/OTP 18.0 has been released

  • ライセンスが APL 2.0 へ
  • スケジューラー周りが整理されパフォーマンスが良くなった
  • 18.0 がバイナリーメモリーリークを持っているというオチ。
  • ets:update_counter/4 、デフォルト値取れるようになったの本当に大きい
  • 時間が整理された、これで時間がクソということもなくなった
  • map が実験的リリースじゃなくなった

rebar3

rebar3

色々頑張って出てきて、そろそろ移行できそうだなーという感じ。rebar お疲れ様。

DTLS 1.0/1.2 の実装

Erlang で 1 から DTLS 実装してみたけど、動いて良かった。gen_fsm って意外に使えるんだなと思ったり。思ってるより実装すればできるもんだという自信がついた。

ただ TLS と混在させたり 1.0 と 1.2 を混在させたりするのは死ぬ。ツライ。

Elixir

いろいろなところで流行っていて良い感じ。Elixir が流行ると Erlang へのフィードバックも増えるのは嬉しい。

自分が使うことはないが、このままの勢いで頑張っていって欲しい。

crypto の EVP 対応

crypto の AES-CBC 以外は AES-NI に非対応なので、色々パッチを送ってもらったが、 19 で一通り EVP 対応になるようだ。よかった。

relx

皆 relx を使うようになったようだ。rebar3 や relx のテンプレートエンジンは @soranoba 氏が書いてるというのを皆もっと知った方がいい。

RabbitMQ 3.6.0 リリース

Cowboy 作者が手を入れて TCP は非同期なアンドキュメントライブラリから ranch へ。
そしてビルドは erlang.mk になった。とても素晴らしい事だ。

Erlang の限界

1プロセスの性能という面で Erlang の限界と向き合った一年だった

Erlang の場合性能は I/O 周りか、プロセスキューのどちらかが課題になることがほとんどだろう。もちろん暗号であれば CPU 問題もあるが、まぁそれは置いておく。

その辺を考えて Golang や Rust を検討はしていたのだが、結局のところ単体の性能(暗号やコーデック、演算処理以外)を考えるのであればそもそも分散させてしまった方が良い。

単体の性能を求めるのであれば Golang を頑張る、ただ Erlang で分散させた方が現実的なのではないかというオチまではたどり着いた。

Docker と Consul を組み合わせたりしてクラスタリングをうまく簡単に作る仕組みを作っていった方が良いのではないか。

もちろん 1 プロセスの性能が遅すぎてつらくなるというのは今後もでてくるだろう。そのときは苦労して Golang でリライト、その課題をあきらめるかという選択肢をとることにする。

Issue Tracker の公開

http://bugs.erlang.org/secure/Dashboard.jspa

今まで非公開だったのが公開された。これは大きな一歩だ。

これからの Erlang

19 系では公式なパッケージマネージャーが入る。 rebar や erlang.mk とどううまくやっていくのか気になる。

18.3 は 2016 年の四月頃、19 は 2016 年の 夏頃と考えて良いだろう。

長期的な視点がまずある。

  • Error Logging は今のちょっとしょぼいところから脱却
  • Erlang Node の 100 以上で動かす話
  • cross コンパイルや embedded コンパイルの話
    • クロスコンパイルは早く来て欲しい ... すでに来ているがさくっとできない

長期的な視点だと課題である性能にやはり注目している。

  • JIT
  • I/O 部分

Erlang に足りないというか、求めるのが難しいのはわかっているがパフォーマンスだ。Erlang がかなり不満なく早くなるとなれば、もう Erlang でいいよねになることは間違いない。

性能に少しでも貢献できるように勉強していかねばならないと思っている。

Top comments (0)