2015年3月29日

非同期プログラミングの難しさとScalaのFuture

7
Toshiyuki Takahashi @tototoshi

@edvakf 2つめはFuture[Either[E,T]] 派というかモナドトランスフォーマー派だと思いました。この場合はEitherTじゃなくてOptionT使うと思います。

2015-03-26 10:30:37
Toshiyuki Takahashi @tototoshi

@edvakf Scalaだとモナドトランスフォーマーそんな一般的ではないので普通の人は妥協して、もしくはそういうものとして最初の形にすると思います。最後のやつはIOとして想定しているのがDB以外もある気がしてなんとも言えないですが、よく見るパターンではないです。

2015-03-26 10:32:27
Toshiyuki Takahashi @tototoshi

@edvakf あと別の話で、asyncなドライバー使ってない限りJDBCはブロックするので、Futureで返すよりはそのままOptionを返して、使う側でFuture.successfulでラップする、というのが良い気がします。

2015-03-26 10:35:23
Atsushi Takayama @edvakf

@tototoshi Future でブロッキングコードをラップするという誘惑に駆られるかもしれないことに注意してください playframework.com/documentation/… というのが気になってます。Future.successfulするぐらいなら同期でいいのかなーと。

2015-03-26 12:27:52
Toshiyuki Takahashi @tototoshi

@edvakf Futureでラップ、というのはFuture.applyを使ったものを言ってるんだと思います。Future.applyだと下手するとスレッドプール食いつぶすのでよくないです。

2015-03-26 12:33:38
Toshiyuki Takahashi @tototoshi

@edvakf 一方Future.successfulはすでに計算で得られた値をFutureでくるむのに使うものなので特に心配いらないです。

2015-03-26 12:35:19
Atsushi Takayama @edvakf

@tototoshi ほうほう。Future.successfulだとブロックするのは変わらないのですね。基本全部Future.successfulにしておいて、スループットが必要なところだけ本当の非同期にするのが良さそう。

2015-03-26 12:38:53
Kazuhiro Sera (瀬良) @seratch_ja

前後関係がある Future 処理を一つの処理として抽出すればシンプルなケースではおかしなことにはならないと思うけど real world では横からはさみこみたくなる要件が継ぎ足されていくとつらくなる。

2015-03-26 21:07:59
Kazuhiro Sera (瀬良) @seratch_ja

そういう要件は本当は同期処理でやるのがよいわけで、そこをあえて Future とかコールバック関数縛りでやらなければならない理由が何かを考える。リソース効率とか膨大な同時接続への耐久性を可読性を犠牲にしてでも得たいのかという。

2015-03-26 21:18:34
Toshiyuki Takahashi @tototoshi

Playの場合Futureを多用するから同期処理もFuture型合わせゲームみたいになるときあるんだよなあ。

2015-03-26 21:20:25
Kazuhiro Sera (瀬良) @seratch_ja

適当に作るとデバッグとか運用のトラブルシュートとか大変になるし、開発の難易度はそれなりに上がると思う。本当にトラフィック数や同時接続がすさまじい環境なら別だけど、そうでもない案件の場合だとそこを頑張るのって見合ってるのかなと。

2015-03-26 21:25:06
Kazuhiro Sera (瀬良) @seratch_ja

"Future の先の隠蔽された世界" 感

2015-03-26 21:36:05
Atsushi Takayama @edvakf

Future使うのと使わないのでプログラムの構造をかなり変えないといけないのが諸悪の根源だな。

2015-03-27 05:37:23
Atsushi Takayama @edvakf

モナドトランスフォーマーは使っていくべきな気がしてきた。モナドじゃない値をモナドにするだけでも大変なのに、2階層とか考えたくもない

2015-03-27 05:52:55
しいたけ @yuroyoro

Future についての私見 - seratch's weblog in Japanese seratch.hatenablog.jp/entry/2015/03/…

2015-03-27 19:45:24
しいたけ @yuroyoro

お前らが、DBやファイルアクセスなど全ての処理を非同期コールバック意識して書かねばならない辛みと引き替えに得たいものは一体なんなのか? という話

2015-03-27 19:49:18
しいたけ @yuroyoro

Futureが辛いなら限定継続を使えばいいじゃない

2015-03-27 19:50:35
neuecc @neuecc

async/await使えばいいとオモイマス。ScalaはScalaでこの辺の決定打/作法ないのね……。 / “Scala - DBから単一SELECTする関数の型をFuture[何]にすれば良いのか悩む - Qiita” htn.to/AT511f

2015-03-27 19:51:35
Toshiyuki Takahashi @tototoshi

横からはさみこみたくなる要件が継ぎ足されていくとFutureがつらくなるってのはよくわかんないかも

2015-03-27 20:13:26
Kenji Yoshida @xuwei_k

べつにasync/awaitであまり解決しないよなー? C# 詳しくないからわからんけど。ただ「for式使え」と言われてるのと大差ない気がする twitter.com/neuecc/status/…

2015-03-27 20:30:17
Kazuhiro Sera (瀬良) @seratch_ja

@tototoshi 分岐処理が増えるとやりくりする感じになるよねっていう感じですね。そこだけ同期にしちゃえば楽になれるけど、それが広がりすぎると何のための Future だったんだっけってなるし。

2015-03-27 20:31:36
Toshiyuki Takahashi @tototoshi

@seratch_ja Future自体がめんどうというのはわかるんですけど、分岐が多いとめんどうというのがあまりピンとこないです。結局for式の中で普通に分岐書くだけのような?と思ったんですが。

2015-03-27 20:38:50
Kenji Yoshida @xuwei_k

Futureは"未来を表す"とかいう変な厨二病的なものではなく、単なる純粋データ構造として表現もできて、それを理解できると色々非同期プログラミングに対する考え方が変わるかもしれない?ので、いいからFP in Scala(もしくはその翻訳本)を読みましょう

2015-03-27 20:40:24

コメント

コメントがまだありません。感想を最初に伝えてみませんか?