2017年注目していきたい技術

2017-01-01

番外編

κeenです。毎年これやっていく。個人的に注目していきたい技術と飛び込んでみたい技術書いく。

あくまで個人的な内容。

WebAssembly

ブラウザ上で動く仮想アセンブラ。ブラウザ上でのJSの高速実行はブラウザでの至上命題である。 JIT技術を各ブラウザベンダが切磋琢磨していたがそれでも限界があるのでasm.jsなんかが産まれた。これは例えば

function geometricMean(start, end) {
  start = start|0; // start has type int
  end = end|0;     // end has type int
  return +exp(+logSum(start, end) / +((end - start)|0));
}

のようにx|0と書くとxが整数であることを表わす、などとしてJSのサブセットで型情報も付与出来るようにしたものだ。冗長なので人の手で書くことは意図していない。これはある程度上手くいって、emscriptenのようにLLVMからjsへのコンパイラでも使われている。

それでもまだ問題がある。1つに、JSよりも冗長な記法を使っているためファイルが嵩張る点。ロード時間やパース時間が長くなる。そもそも人の手で掛かないならバイナリフォーマットでもいい筈だ。そしてもう1つに低レベルな処理、例えばSIMDなんかは扱えない点。

WebAssemblyはこれらを解決する。仮想的な機械語でバイナリフォーマットがあるので低レベルなことが（将来）出来てコンパクトになっている。計算モデルはスタックベースのマシンになっている。メモリや関数テーブルなどもある。

(module
  (type (;0;) (func (param i32 i32) (result i32)))
  (func (;0;) (type 0) (param i32 i32) (result i32)
    get_local 0
    get_local 1
    i32.add)
  (export "addTwo" (func 0)))

多くの人にとってWebAssemblyは意識して関るものではなく、emscriptenの吐くコードが効率的になる、程度のものだろう。私はコンパイラを作る人なので意識する必要がある。 WebAssemblyにはundefined behaviourがないだとかThread API、 SIMD APIなどが入る予定だとかがあるのでLLVM経由で吐くよりも直接吐いた方が面白い。

少し追っていきたい。

QUIC

HTTP/2のための代替TCP。HTTP/2はもうリリースされてるので次はQUICを。 HTTP/2は1コネクションを複数のstreamに分割するが、stream内での到達順序保障は必要なもののstream同士ではそれが不要なのでTCPの到達順序保障が過剰要求になってしまう。それを緩めるためにUDPベースでプロトコルを作ったのがQUIC。まあ、他にも色々改善点はあるが。

これも基本的にはあまり追う必要はないが、自分の使いたい言語で実装がなかったら自分で実装することになる。まだその辺の環境が整っていないので今後どうなるか注視する必要がある。

Idris

依存型のある言語。今年もRustに忙しい可能性があるが、ちょっとIdrisに興味が湧いた。常々「多相があって正格評価で高階関数を簡単に扱えてサブタイピングのない、C FFIやThreadを扱える言語」を捜していて、それがATS2だったりSML#だったりRustだったりした。最近はRustに落ち着いたが、今度は低レベルな部分、「C FFIやThreadを扱える」がなくてもいいから依存型が入ってる言語が欲しくなった。ATS2は置いといてIdrisかなーと。

生の依存型だとつらいかな、と思っていたらtacticもあるようだったので機会があればやってみたい。

CF プログラミング言語 idris - wkwkesのやつ

Lean

MSRで開発されている定理証明支援系。よく「Coqでいいじゃん」「Agdaは？」と訊かれるが、オンラインチュートリアルが良さげだったのと、Emacsから使えるのと、 RustからLeanへのトランスレートをやっている人がいたので興味湧いた。そもそもCoqをある程度やってからにしろとは自分でも思う。

Coq

定理証明支援系。去年も上がっていたが、今年は酉年なので。「Agdaは？」。知らん。

Finagle

RPCのクライアント/サーバフレームワーク。RPCをやる時にいくつか問題が出る。 1つはペイロードがRPC毎に違うのでフレームワークが定まりづらい点。もう1つはロードバランシングがしづらい点。ロードバランシングの方に言及しておくと、RPCをやる時は大抵コネクションを張りっぱなしなのでTCPロードバランサが使えない。例えば順番にサーバを起動していくと最初に上がったサーバにコネクションが集中して以後バランスされない。

これを解決するのがFinagleで、クライアントが全てのサーバにコネクションを貼って、クライアントサイドでロードバランシングをする。さらにクライアントが複数のサーバを知っているのでサーバがエラーを返したら別のサーバにリクエストを投げることも出来る。ペイロードの話は多相型で解決する。パーサとかその辺も含めたフレームワークになっている。

Tokio

FinagleのRust版。Rustは非同期IOに強いと思っているのでTokioがリリースされたらそこら辺のHTTPフレームワークも非同期化するのではと思っている。

TiDB

分散スケール可能なSQL DB。Rust製。Google F1を参考に作られているらしい。ストレージエンジン自体はRocksDBを使っていて、その上に分散合意、MVCC、トランザクションを載せてさらにそれにSQLレイヤー、MySQLプロトコルレイヤーを載せている。

TiDBのアーキテクチャ画像

アーキテクチャについては上の画像を引用したこの記事が詳しい。

tantivy

全文検索エンジンライブラリ。Rust製。アーキテクチャやアルゴリズムはApache Luceneを参考に作られているらしいのでだいたいそのレイヤーのライブラリと思ってもらえれば。

Rust製なのでインデックスの構築が速いのが一つの特徴。今後、自前でElastic SearchやApache Solrのようなレイヤーを作るのかLuceneの置き換えを狙ってJava APIを提供するのかは不明。

注目したい理由はベースで使っているfstライブラリの紹介記事が気に入ったから。