响应式宣言：非阻塞代码与阻塞代码？
Reactive manifesto: non blocking code vs blocking code?
这些天似乎每个人都在谈论 Reactive 应用程序，Reactive 宣言似乎鼓励非 blocking/asynchronous 代码。我在 youtube 上看过很多视频，其中的演讲者都在鼓励非阻塞代码，但除了说
之外，没有人说编写非阻塞代码比阻塞代码的好处
"using futures is good because it is not blocking your code" - some speaker
这只会让“阻塞代码”听起来像个坏词。
我的问题很简单： 如果我有一个任务并且我 运行 它是：
- 阻塞代码 - 其中 运行 是一个线程上的任务
- 非阻塞代码 - 一个线程将任务委托给另一个线程
事实是，在上述两种情况下，我想要 运行 的实际任务总是在 1 个线程上 运行。第二个选项只会增加应用程序的复杂性，而第一个选项更简单并且可能更快，因为我不必委托。
我知道在执行任务期间的某个时候需要执行多个并发任务，因此 Threads/non blocking/async 代码在这里有所帮助。但为什么 Reactive 宣言鼓励非阻塞应用程序从头开始？除了应用程序中的一大堆 Futures 和 Promises 只会使代码更复杂且更难调试之外，还有什么好处？
Non blocking code - Where one thread delegates the task to another thread
事实并非如此。非阻塞 IO 有各种形式，但通常在 IO 运行 时没有线程阻塞。 IO 完成时调用回调。
这就是 non-blocking/async IO 如此难用的原因。它将您的代码转换为回调。
non-blocking/async IO 的两个好处：需要更少的线程和更少的上下文切换。在某些情况下，它可以使使用交互式 GUI 进行编程变得更加容易。
Non-blocking/async IO 当然不应该是默认选择，因为它会导致生产力下降。
我已经在 .NET 上下文中写了两篇关于此的标准文章，我将 link 用于： 为什么 EF 6 教程使用异步调用？
我们应该切换到默认使用异步 I/O 吗？
这些概念应该适用于大多数平台。
这些天似乎每个人都在谈论 Reactive 应用程序，Reactive 宣言似乎鼓励非 blocking/asynchronous 代码。我在 youtube 上看过很多视频，其中的演讲者都在鼓励非阻塞代码，但除了说
之外，没有人说编写非阻塞代码比阻塞代码的好处"using futures is good because it is not blocking your code" - some speaker
这只会让“阻塞代码”听起来像个坏词。
我的问题很简单： 如果我有一个任务并且我 运行 它是：
- 阻塞代码 - 其中 运行 是一个线程上的任务
- 非阻塞代码 - 一个线程将任务委托给另一个线程
事实是，在上述两种情况下，我想要 运行 的实际任务总是在 1 个线程上 运行。第二个选项只会增加应用程序的复杂性，而第一个选项更简单并且可能更快，因为我不必委托。
我知道在执行任务期间的某个时候需要执行多个并发任务，因此 Threads/non blocking/async 代码在这里有所帮助。但为什么 Reactive 宣言鼓励非阻塞应用程序从头开始？除了应用程序中的一大堆 Futures 和 Promises 只会使代码更复杂且更难调试之外，还有什么好处？
Non blocking code - Where one thread delegates the task to another thread
事实并非如此。非阻塞 IO 有各种形式，但通常在 IO 运行 时没有线程阻塞。 IO 完成时调用回调。
这就是 non-blocking/async IO 如此难用的原因。它将您的代码转换为回调。
non-blocking/async IO 的两个好处：需要更少的线程和更少的上下文切换。在某些情况下，它可以使使用交互式 GUI 进行编程变得更加容易。
Non-blocking/async IO 当然不应该是默认选择，因为它会导致生产力下降。
我已经在 .NET 上下文中写了两篇关于此的标准文章，我将 link 用于： 为什么 EF 6 教程使用异步调用？ 我们应该切换到默认使用异步 I/O 吗？
这些概念应该适用于大多数平台。