10年ほど前、業務システムがあるべき姿を追い求めて Reactive Manifesto に行きつき、 reactive programming に傾倒していたことがありました。Vert.x を使ってすべてをイベントの流れであるとみなしたコードを書き、backpressure で全体の負荷を制御しつつ、ハードウェアを使い切れるソフトウェアを実現できるのではと思っていたのです。。単純な並列処理・並行処理に比べて思想としては背骨を感じるし、CompletableFuture やProject Reactorなんかも出てきていい感じだなと思っていました。
……ええ、思ってはいたんですが、例外もイベントとして扱うためにどうしても try-catch ベースのハンドリングに比べて異常系処理の見通しが悪くなりやすく、単に RDBMS から取り出したデータをストリームとして扱いたいだけなのに複雑なおまじないが必要だったり、ページング処理の書き方を検索しても見つけにくかったりと、難しさに直面してフェードアウトしてしまいました。
とはいえ並列処理・並行処理のニーズが消えたわけではないので、どのような書き方に落ち着いていったかというと、Kotlin の suspend や Java の Virtual Threads のような逐次的な制御構造を保てる書き方です。JEP 444 に書かれているこの課題意識がまさに当時の自分の意見を代弁してくれているように感じます：
They thus forsake the language's basic sequential composition operators, such as loops and try/catch blocks.
なんでこんな話を急にしたかというと、最近 Write-Ahead Logging から別インスタンスでのデータ更新を再現するという、リードレプリカ的な機能を趣味で実装していたんですが、そこで Flow が出てきたんですよね。自分の中では structured concurrency が有力になって、everything is a stream という夢から離れても、あるところにはきちんと stream が流れているんだなぁというか。色々知って使い分けることにしっかりと価値があるんだなぁというか、そういうことを考えたのでした。
