bxq*_*bxq 12 java asynchronous reactive-programming netty java-loom
我可能错了，但据我所知，整个Reactive/Event Loop 的事情，尤其是Netty，是为了解决C10K+问题而发明的。它有明显的缺点，因为您的所有代码现在都变成了Async，带有丑陋的回调，无意义的堆栈跟踪，因此难以维护和推理。
带有 goroutines 的Go语言是一个解决方案，现在他们可以编写Sync代码并处理C10K+。所以现在Java提出了Loom，它基本上复制了Go的解决方案，很快我们将拥有Fibers和Continuations，并且将能够再次编写Sync代码。
所以问题是：
当Loom投入生产时，是不是让Netty有点过时了？
如果我们在Java 中有Fibers和Continuations，我们能写出漂亮的Sync代码并且在没有Netty 的情况下使用C10K+吗？
在Loom 的生产版本发布后，在编写Async代码和使用Netty方面，对于性能或解决C10K+是否有任何优势？
我知道Netty不仅仅是Reactive/Event Loop框架，它还拥有各种协议的所有编解码器，这些实现无论如何都会有用，即使在之后也是如此。
我重点关注 Netty 的反应部分，因为您似乎最想在一般层面上解决这些问题：
当前反应式编程范式常常被用来解决性能问题，而不是因为它们适合问题。这些应该通过 Loom 项目完全覆盖。
然而，在反应式编程方法有意义并且比命令式代码更容易阅读的情况下，可能仍然存在一些问题。反应式框架通常是面向流的，非常适合组合不同实体/数据流上的元素和操作。他们还通过其提供商/订阅者模型提供直接的本地事件总线解决方案。在这种情况下，反应式模型可能仍然是最佳选择，比命令式方法性能更高且更具可读性。但事实上， Loom 项目应该使所有由于缺乏对母语结构更好的支持而导致的“误用”变得过时。