「Erlang 30% + JavaScript 60% + 未知成分 10%」のセミナー

告知:「Erlang 30% + JavaScript 60% + 未知成分 10%」のセミナーやります - 檜山正幸のキマイラ飼育記
プログラミング言語によらない、通信基盤にもよらない、関数呼び出し(function call)とイベント配信(event delivery)が主題

Erlang

プログラミング言語としてのErlangの話は↓を嫁

プログラミングErlang

プログラミングErlang

システムとしてのErlang
  • それ自体が完結したコンピュータシステム
  • 仮想ハードウェア上に仮想OSが載り、アプリケーションが走る
  • 仮想ハードウェア…エミュレータと呼ぶ
  • 仮想ハードウェア+OS(シェル、基本アプリケーション含む)=ERTS
  • 大量の軽量プロセスを使えることがウリ
    • SUNのメモリたんまりマシンで4000万プロセスとか
    • 普通のPCでも数万走らせるとか普通にできる
  • プロセス概念は通常のOSとそんなに変わらない
  • 1プロセス1スレッド
    • 1スレッドなので1スタック
  • 対話的モードではEshellが現れ、ユーザとの対話を行う
    • Erlangの構文と同じコマンドが使える
    • 関数の定義とかできない
  • Webサーバとしては、非対話的モードで実行する
    • というか、むしろ、本格的な用途では非対話的モードが多そう
  • 抽象機械語=CoreErlang(形式的・操作的意味論があるらしい)
    • アカデミックな話だけじゃなくて実用上でも使われている
  • 具体的機械語=JAM機械語,BEAM機械語(仕様は実装?)

(高級言語の)Erlang→Core Erlang(意味論)

JAM

Core Erlang→BEAM

??
Core Erlangから様々な具体的機械語に変換される。
今は主にBEAM機械語だけど、その内もっといいのが出てきたら差し替えることも可能。

JVM上の様々な言語のように他言語→Core Erlang
というのも理論上可能だけど、実際Erlangに依存しすぎてるので難しい。

エミュレータ/ERTS
  • initが最初のプロセス
  • kernelとstflibはすべてErlangで書かれている
  • ファイルシステムやネットワークはホストOSの機能をそのまま利用
    • サーバプロセスを被せているので、やりたければどうにでもなる
  • エリクソンとしてはハードウェアを作りたかったのではないか?
YAWS
  • Erlangで実装されたWebサーバ
  • 静的リソースについては特徴無し
  • 大量のコネクション/セッションを捌けるらしい
  • HTML内にインラインで書かれたErlangコードを処理出来る
    • 昔風のPHPっぽくてキモイ
  • 他のErlangアプリケーションと直接的に連携出来る
  • Eralngアプリケーションに対して、Webからのリクエストの窓口に使える
    • ErlangアプリケーションのWebAPI化に使える
さて、Erlangはなんでしょう?
  • 汎用言語というには嘘くさい
  • 交換機を作る為の言語/システム
    • YWASもあるからWeb上の交換機なんてどうだろうか?

→Web Communication Channels

質疑応答
  • 他言語のライブラリ等を呼ぶにはどうするか?
    • Cでdriver書く
    • ただC等で書かれた部分の処理時間が長いと、そこが動いている間はErlangの並列処理のありがたみが生かせない
  • 正規表現ライブラリもマッチする所だけCで書かれていて、他ほとんどErlangとかそんな感じ

Web Communication Channels

発端
  • Webアプリケーションを作るのは、サイトの所有者
  • ブラウザ利用者はサイトと独立にアプリケーションを作れないのか?
ブラウザ上のアプリケーション

→サイトに縛られる

通信機能とストレージ
  • 中立な中継サイトを設けて、できるだけ透過的にブラウザ-ブラウザ通信をサポートする。
  • 永続的なストレージも提供する
  • クロスドメインHTTP通信が必須

デモだとローカルファイルのHTML+JavaScriptを二つのブラウザで表示、
JSONPで中継サイト経由で通信して、片方からもう片方にメッセージを送った。
同じ仕組みを使ったデモだと、両方ローカルファイルを使っているが、
片方がサーバ的な振る舞いをし、もう片方がクライアント的な振る舞いをするということをやっていた。

別の動機
  • サーバ側もJavaScriptで書けたらいいんじゃないか?
    • 既にあるけど流行ってない
  • JavaScriptプログラムがローミングしたら面白いのでは?
    • 無理ぽ
    • JavaScriptのサブセットならどうよ?→無理ぽ
Erlangがお手本
  • Erlangではノード=ERTS
    • 複数のERTSの固まりを以てクラスタと呼ぶ
    • EDPというプロトコルでやり取りする
    • 各ノード内でたくさんプロセスが動いている
      • 同一ノード内のプロセス間・ノードをまたがるプロセス間のメッセージングはほぼ同じ

→WCCではブラウザもノードとして使えるようにしよう!!

  • ブラウザ上で動く動作主体をエージェントとし、エージェントIDをつける。
    • このIDがErlangでのPIDに対応する
アリモノをツギハギ
  • JavaScriptのイベントモデルはW3C DOM3から
    • ちょっと先走り
    • 具体的になに?
  • 外部からのコールバックはActionScriptのExternalInterface
    • 関数呼び出し→返さないと行けない≠event
  • データ形式は徹底的にJSON、ただし抽象的データ形式として
  • OMG IDLのサブセットで仕様記述の予定(全然できてない)

標準と折り合いを付けるのは大変

COMET
  • ブラウザごとの挙動の違い
  • JavaScriptのシングルスレッドに泣く
  • サーバから見ると貼りっぱなしのコネクションが増えまくってサーバ資源が浪費されまくる
    • YAWSなら同時接続数がアホみたいに多くても対応出来る
Erlangについて
  • フォールトトレランスや実行時コード置き換えができる
    • 止めないでbug fixできないと電話交換機だと色々困るでしょう。
  • 武士道プログラミング「不要なことは書かない」「いさぎよく死ぬ」「一人で死ぬ」
    • プロセスいっぱいあるから
    • 体細胞の1個1個が死んでも命に別状はないのと同じ
問題
  • 色々いっぱい
  • 何が嬉しいのかよくわからない。→大問題
eventとか
  • 中継サーバをまたいだ向こう側でどうこうみたいなeventを作ったりとか