[Swift 4] Support an official reactive library

With swift 3 around the corner, I wanted to propose some higher level focuses for version 4.
My first suggestion is an official reactive library. Reactive programming has gained a huge amount of popularity especially with reactive cocoa and rxswift.
Microsofts support of the original Rx library is a big help in this.
I believe the apple ecosystem would benefit from offering this same support to an official library, why?
- RxSwift in particular is pushing the limits of the compiler and often crashes source kit. I believe if we had an official library we could have tighter feedback to the compiler team.- it would help address the complexities of async code without reinventing the wheel.- it could reduce app size. RxSwift is a large framework right now but I would imagine with the right system knowledge it could be refined and the API simplified with an official library.
Let me know your thoughts

ยทยทยท

Sent from Supmenow.com

I have nothing against reactive programming, but I don't agree that a reactive library should be an official Swift.org project focus in the near future.

- Lower-level concurrency has already been described as a more pressing matter than any sort of opinionated higher-level framework, and will already require significant effort (no matter what form it takes) to implement, both in the form of language changes as well as rewriting the standard library (and to a lesser extent, Foundation) to take advantage of the new constructs. As well, it's likely that a reactive programming framework's design would be greatly dependent on how native Swift concurrency ends up being implemented.

- I don't think the compiler team bugfix rate is constrained by lack of bugs to fix. More importantly, I don't think compiler bugs affecting a certain project should be privileged over those affecting other projects unless there is an extremely compelling reason to do so. Otherwise, there isn't a need for 'tighter feedback' - anyone can file bugs on the Jira as it is.

- Given that all the important parts about Swift are open-source and available for public examination, I don't think there is any special system knowledge to be gained by conferring 'official' status upon a project. Rather, projects should propose features and enhancements they feel are both beneficial to their specific use cases as well as useful to the wider community, and then take advantage of those features to provide better APIs.

- There are already widely-used non-official frameworks which provide this functionality. I think the benefit of providing an 'official' implementation would have to be extremely large in order to justify allocating Swift project resources towards duplicating the community's work.

I think a better approach would be to determine what sort of criteria would justify the Swift.org project blessing any non-fundamental library with 'official' status (e.g. logging, web servers, cross-platform UI, whatever), and then using those to justify why Swift should officially support a reactive library.

Best,
Austin

ยทยทยท

On May 10, 2016, at 12:41 AM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

With swift 3 around the corner, I wanted to propose some higher level focuses for version 4.

My first suggestion is an official reactive library. Reactive programming has gained a huge amount of popularity especially with reactive cocoa and rxswift.

Microsofts support of the original Rx library is a big help in this.

I believe the apple ecosystem would benefit from offering this same support to an official library, why?

- RxSwift in particular is pushing the limits of the compiler and often crashes source kit. I believe if we had an official library we could have tighter feedback to the compiler team.
- it would help address the complexities of async code without reinventing the wheel.
- it could reduce app size. RxSwift is a large framework right now but I would imagine with the right system knowledge it could be refined and the API simplified with an official library.

Let me know your thoughts

Sent from Supmenow.com <http://supmenow.com/&gt;
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4 Likes

Reactive programming is still catching on and evolving on the various platforms.Typically once you standardize something it must evolve drastically slower, so it works out better if mature technologies are pulled in.

I wouldnโ€™t mind eventually seeing something analogous to http://www.reactive-streams.org in Swift. Reactive streams takes a step beyond most of the other reactive framework APIs and adds back pressure support. These API were driven by consensus between many projects on having a common base set of interfaces for implementation, and are being incorporated into the Java 9 release as well (as java.util.concurrent.Flow).

Right now I donโ€™t think the various reactive programming libraries for objective-C and swift are close to having consensus on a baseline set of protocols, so I would imagine standardizing reactive programming would mean either picking a winner or adding yet another competitor to the mix.

-DW.

ยทยทยท

On May 10, 2016, at 1:41 AM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

With swift 3 around the corner, I wanted to propose some higher level focuses for version 4.

My first suggestion is an official reactive library. Reactive programming has gained a huge amount of popularity especially with reactive cocoa and rxswift.

Microsofts support of the original Rx library is a big help in this.

I believe the apple ecosystem would benefit from offering this same support to an official library, why?

- RxSwift in particular is pushing the limits of the compiler and often crashes source kit. I believe if we had an official library we could have tighter feedback to the compiler team.
- it would help address the complexities of async code without reinventing the wheel.
- it could reduce app size. RxSwift is a large framework right now but I would imagine with the right system knowledge it could be refined and the API simplified with an official library.

Let me know your thoughts

Sent from Supmenow.com <http://supmenow.com/&gt;
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hi James,

While Swift 3 is winding down in some ways, it is still far from done. Iโ€™d really prefer to keep this mailing list focused on Swift 3 issues.

Also, since this is a new library, there is no reason it needs to be discussed here. There are a number of reactive projects.

-Chris

ยทยทยท

On May 10, 2016, at 12:41 AM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

With swift 3 around the corner, I wanted to propose some higher level focuses for version 4.

We built a reactive streams implementation for Vapor (and Swift 4.1). It was initially a direct copy of the Java spec you mentioned, but we've since simplified it a bit to meet our needs. (Still supports back-pressure obviously)

You can check it out there, this code will eventually be moved to the master branch when we merge beta (mid-Marchish)

We're still anxiously waiting to see what the Swift Server APIs Transport group will come up with, but we've seen really incredible performance out of the streams so far (combined with a Node.js/Vert.x-like multi-reactor design). We're measuring speeds far faster than Node.js and slightly ahead of Golang-based frameworks.

4 Likes