あくまでざっと調べたメモなので間違いもあるかも。読む人は疑って読んでください。

手が式で、modelのpredictが遅くなってきたので非同期になおして裏のスレッドでやるようにした。 encoder-decoderモデルなので、decoderのpredictが何度も走る。 新しい入力があったら途中でキャンセルしたいので、それっぽい仕組みを探していたところ、flowを見つけて少し調べたので雑感を（結局使わなかった）。

まず次のcoroutineのリリースにflowというものが入る。 これは一見するとReactiveStreamに似てるし実際その一実装との事だが、 cold streamだけを扱うところが違う。

cold streamは、呼び出しの間以外では処理が動かない種類のストリーム。 だから例えばpublisher subscriberモデルでpublisherがずっとUIにひっついてイベントが来る都度何かをemitし、subscriberがずっと待って来たら処理をする、みたいなのは書けない。

subscribeという概念は無い。基本的にはストリームを作る、というもので、作ったストリームは最終的にはcollectで取り出せる。 気分的にはSparkに似てる。

hotなストリームで似たような処理をする時には全く違う従来の書き方をしないといけないのがいまいちな気がするが、coldなストリームを作るだけ、と割り切っているおかげでデザインはシンプル。 しかも下はチャンネルとか従来のプリミティブにつながるので、これまでの事を理解しているとますます理解は容易。 現状はドキュメントが無いので理解するのに苦労したが、ドキュメントが整備されればすぐ理解出来そう。

次のリリースでexperimentalじゃなくなる、との事なので、もう使っても良さそう。 また、actorとかのとりあえず作ってみました、くらいのノリじゃなくて割と本気で作っている感じで、 今後はなるべくこれベースにしていきたい、くらいのつもりっぽくて、開発リソースも大量に突っ込まれていそうな感じがある。 以後はなるべくflowで書けるものはflowで書いていくのが良さそう。

一方でAndroidのUI関連は全部ホットなストリームになると思うので、使えない気がする。 リクエストとかそっち側をflowにすれば良いので使いみちはあるとは思うが、 RxJavaはUI側も同じように書ける訳で、そこはちょっと不思議な感じはした。