关于响应式编程，大家来吹吹水

[MakHoCheung]

• ReactiveX
• Reactive Streams

1. 上面两个有啥区别呀，
2. 响应式编程在异步这块感觉不如协程 /(async/await)，后者写得舒服些，简单数据流处理有 Java8 Stream API ，当然复杂的情况或者需要背压的情况下响应式编程占优势，那么还有什么场景值得去用呢
3. RxJava 和 Reactor 让你选你更倾向哪个？

[sagaxu]

后端这块儿，响应式和协程都用过几年，最后把项目所有代码重构到协程了，没遇到过响应式更有优势的场景

[gouflv]

就算前端也很少复杂到要用 rx

[WispZhan]

Reactive Streams 是 JDK9 加入的标准。
目前 Project Reactor 是基于 ReactiveX 之上更进一步的实现，同时它实现了 Reactive Streams 。

响应式对数据流和处理封装更完善，两者（ reactive 和协程）解决的问题和层次都不一样。

虽然都有异步，但协程是简化了异步实现。reactive 可以可以在协程上实现执行和调度。

[freedomSky]

Reactive Streams 是规范，ReactiveX/Reactor 是实现

[chihiro2014]

=。=去年翻译了龙之春的 reactive spring ，结果被出版社以响应式不火为由拒了。

响应式编程（ Project Reactor ）对各种突发情况已经封装了相应的 API ，直接调用即可。让业务人员更专注业务

[TomVista]

举个对比的例子:
flutter 应用了大量的响应式编程设计, 比如 http 请求,视图驱动, 导致 状态处理 异常困难

web 的 promise / async await,已经是基操了,就算用原生 h5+js,写起来也比 flutter 舒服,

[MakHoCheung]

@freedomSky 不是吧，ReactiveX 也是规范，RxJava 是它的一个实现，你可以点链接进官网看。我纳闷的是为啥有两个规范

[MakHoCheung]

@TomVista 是的，我也说了异步用协程比 Reactive 舒服

[yazinnnn]

rx 背靠巨硬
reactor 背靠 spring ，spring 背靠 vmware
mutiny 背靠红帽

用 kotlin 扩展函数的话，这三个 reactive 实现可以互相转换
应用层面，reactor 有 webflux 和 r2dbc ，貌似 r2dbc 使用的驱动是阻塞的
munity 包了一遍 vertx 的 api ，hibernate reactive 也是用的 mutiny+vertx db client ，所以数据库这方面比 reactor 好一些

[MakHoCheung]

@WispZhan 对数据流的处理，感觉 Java8 Stream API 已经很好用了😂

[MakHoCheung]

munity 第一次听，感觉 reactor 靠谱点，毕竟是面向 Spring 吃饭

[MakHoCheung]

@yazinnnn munity 第一次听，感觉 reactor 靠谱点，毕竟是面向 Spring 吃饭

[yazinnnn]

Reactive Streams 不是面向 stream 的，而是面向 flow 的

reactor 还真不一定比 mutiny 靠谱，quarkus 有一套完整的 reactive 拓展就是使用的 mutiny api （毕竟都是红帽的），native 层面领先 spring 太多，未来还不好说，万一 quarkus 在 native 方向或者 reactive 方向干掉 spring 呢

[smilekung]

reactor 用起来更舒服吧 组里落地过 要求组里参与开发都得接受这个理念还是挺难的

[freedomSky]

@MakHoCheung 是的，我搞错啦，当成 RxJava 了：）

[nzbin]

@gouflv 前端用 rx 并不一定针对复杂场景，而是简化逻辑，处理异步操作也会更简单

[Magentaize]

这取决于你的需求，纯粹的业务逻辑自然用不上 rx 。但是对于复杂的状态控制，大量数据流的分析（比如需要从一个 20 通道的采集卡上做聚合），协程和 stream api 就有点不太好用了。