因此，现在有了Swift，人们已经在3.0版中为Swift重写了它。

另外，还有另一个项目，叫做RXSwift。

我想知道人们是否可以添加关于这两个框架在设计/API/哲学上的差异的信息(请本着这样的精神，坚持正确的事情，而不是关于哪个是"最好的"的意见)。

[注意stackoverflow mods：这个问题有明确的答案，答案是两个框架之间的差异。我认为这也是非常热门的话题]

首先，我从阅读他们的自述文件中得到的初步印象是：

• 作为一个熟悉微软"真正的"C-RX的人，RXSwift看起来更容易识别。
• ReactiveVecocca现在似乎已经进入了它自己的空间，引入了新的抽象，比如信号与信号生产者以及提升。一方面，这似乎澄清了一些情况(什么是冷热信号)，但另一方面，这似乎大大增加了框架的复杂性。

这是一个很好的问题。比较这两个世界是非常困难的。RX是其他扩展语言中的反应式扩展的端口，例如C语言、Java或JS。好的。

反应式Cocoa受到功能性反应式编程的启发，但在过去的几个月里，也受到了反应式扩展的启发。其结果是一个与RX共享某些内容的框架，但其名称来源于FRP。好的。

根据Conal对概念的定义，首先要说的是，rac和rxswift都不是功能性的反应式编程实现。从这一点上，一切都可以简化为每个框架如何处理副作用和其他一些组件。好的。

让我们来谈谈社区和元技术的东西：好的。

• RAC是一个3年前的项目，出生于Objective-C，后来移植到Swift(使用Bridges)进行3.0版本，在完全放弃了正在进行的Objective-C工作之后。
• Rxswift是一个有几个月历史的项目，目前似乎在社区中有了发展势头。Rxswift的一个重要问题是，在reactivex组织下，所有其他实现都以相同的方式工作，学习如何处理Rxswift将使使用Rx.net、RxJava或RxJS成为一个简单的任务，只是语言语法问题。我可以说，这是基于哲学学习一次，适用于任何地方。

现在是时候去做技术性的工作了。好的。生产/观察实体

rac 3.0有两个主要实体：Signal和SignalProducer，第一个实体发布事件，不管用户是否连接，第二个实体要求start实际生成信号/事件。这个设计是为了将热观测和冷观测这两个单调乏味的概念分开而创建的，这对于许多开发人员来说是一个混乱的来源。这就是为什么差异可以减少到如何管理副作用。好的。

在Rxswift中，Signal和SignalProducer翻译为Observable，听起来很混乱，但这两个实体实际上在Rx世界中是相同的。在Rxswift中使用Observable的设计必须考虑到它们是热的还是冷的，这听起来可能是不必要的复杂性，但是一旦你了解了它们的工作原理(再次说明，热/冷/热只是订阅/观察时的副作用)，它们就可以被驯服。好的。

在这两个世界中，订阅的概念基本上是相同的，RAC引入了一个小的区别，即在发送完成事件之前处理Signal事件时，interruption事件。概括地说，两者都有以下类型的事件：好的。

• Next计算新收到的价值
• Error计算错误并完成流，取消订阅所有观察者
• Complete，将流标记为已完成取消订阅所有观察者

此外，rac还有interrupted，当Signal在正确完成或出错之前被处理时发送。好的。手动写入

在rac中，Signal/SignalProducer是只读实体，它们不能从外部进行管理，Rxswift中的Observable也是这样。要将Signal/SignalProducer转换为可写实体，必须使用pipe()函数返回手动控制的项。在Rx空间上，这是一种不同的类型，称为Subject。好的。

如果读/写概念听起来不熟悉，可以很好地与Future或Promise进行类比。Future是只读的占位符，如Signal/SignalProducer和Observable，另一方面，Promise可以手动完成，如pipe()和Subject。好的。调度者

这个实体在两个世界中非常相似，概念相同，但rac只是串行的，而rxswift的特性也是并发调度程序。好的。作文

组合是反应式编程的关键特征。组成流是两个框架的本质，在RXSwift中，它们也被称为序列。好的。

Rxswift中的所有可观察实体都是ObservableType类型，因此我们用相同的操作符组合Subject和Observable实例，而不需要额外考虑。好的。

在rac空间中，Signal和SignalProducer是两个不同的实体，我们必须在SignalProducer上lift才能合成Signal实例产生的结果。这两个实体都有自己的操作符，所以当你需要混合东西时，你必须确保某个操作符是可用的，而在另一方面，你忘记了冷热观测。好的。

关于这一部分，科林·埃伯哈特很好地总结了一下：好的。

Looking at the current API the signal operations are mainly focussed on the ‘next’ event, allowing you to transform values, skip, delay, combine and observe on different threads. Whereas the signal producer API is mostly concerned with the signal lifecycle events (completed, error), with operations including then, flatMap, takeUntil and catch.

Ok.

额外的

rac也有Action和Property的概念，前者是一种计算副作用的类型，主要与用户交互有关，后者在观察值时很有趣，当值发生变化时执行任务。在Rxswift中，Action再次转换为Observable，这在RxCocoa中得到了很好的体现，RxCocoa集成了iOS和Mac的Rx原语。rac的Property可以在rxswift中转换成Variable(或BehaviourSubject)。好的。

重要的是要理解，Property/Variable是我们必须将命令世界与反应式编程的声明性本质连接起来的方式，因此有时在处理第三方库或iOS/Mac空间的核心功能时，它是一个基本组件。好的。结论

RAC和RXSWIFT是2种完全不同的动物，前者在可可空间中有很长的历史，还有许多贡献者，后者是相当年轻的，但是依赖于已经证明在其他语言如Java、JS或.NET中有效的概念。哪个更好的决定取决于优先权。rac指出，冷/热观测数据的分离是必要的，这是框架的核心特征，Rxswift说，它们的统一比分离更好，同样，这只是关于如何管理/执行副作用。好的。

rac 3.0似乎在分离冷热观测数据的主要目标上引入了一些意想不到的复杂性，例如中断概念、在两个实体之间拆分运算符以及引入一些必要的行为，如start，以开始产生信号。对某些人来说，这些东西是一件很好的事情，甚至是一个杀手的特征，对其他人来说，它们可能是不必要的，甚至是危险的。另一件要记住的是，RAC正在尽可能地跟上Cocoa约定，因此，如果您是一个有经验的Cocoa开发人员，您应该更愿意使用它，而不是Rxswift。好的。

另一方面，RXSwift生活在所有的缺点上，比如热/冷的可观察性，但同时也有反应性扩展的好处。从rxjs、rxjava或rx.net迁移到rxswift是一件很简单的事情，所有的概念都是相同的，所以这使得查找材料变得相当有趣，也许你现在面临的相同问题已经由rxjava中的某个人解决了，并且考虑到平台的因素，这个解决方案可以重新应用。好的。

从客观的角度看，选择哪一个肯定是一个偏好问题，不可能分辨出哪一个更好。唯一的方法是启动Xcode，尝试两者，并选择一个更舒适的工作。它们是两个类似概念的实现，试图实现相同的目标：简化软件开发。好的。好啊。