What is the difference between PromiseKit and RxSwift?

[rlam3]

What is the difference between PromiseKit and RxSwift?

[nathanhosselton]

I've not looked into ReactiveX/RxSwift, but our brief on Reactive Cocoa is probably relevant (from our docs):

Reactive Cocoa is amazing, but requires a large shift in the way you program. PromiseKit is a happier compromise between the way most people program for iOS and a pure reactive paradigm. However, reactive programming is probably the future of our art.

[mxcl]

In RxSwift terms, Promises are a reactive pattern for asynchronicity.

PromiseKit take the good parts of reactive programming and apply them to the hardest part of pure Swift development.

RxSwift requires you to commit fully to a paradigm shift in how you program. If you do it right your code will be more robust, but you may have trouble finding other developers experienced with reactive paradigms to work on the project.

Promises make code that is pretty clear to most developers.

[sahandnayebaziz]

@rlam3 at a higher level too, Promises (and PromiseKit) are just a tool you can use to write code that needs to go off and do some stuff and return at some unknown time.

Where a simple line print("hello world") executes immediately, something like fetchWeatherIn(state: California) doesn't execute immediately because it makes an HTTP request, and then waits for a response, and then parses the response, (etc, etc, etc). So if you wanted to have something happen after fetchWeatherIn was all done, you'd have to write some tricky code yourself to wait for it to finish, or keep checking to see if it's finished, or something even more clever. Promises are a well-accepted way for writing code like this, and saying "this runs, at some point it comes back when it's finished, and then ..... do the next thing!". Promises also exist in the other big languages, so learning how to use them is valuable for the world outside of Swift.

So with Promises, you can write code that "waits" for things to happen and yet is easy to read. It's possible to do everything you can do with Promises without using Promises, but you'll end up writing a lot of code to do very basic things that have nothing to do with what your app is actually trying to accomplish.

RxSwift is a much bigger idea and promotes a different way of writing apps in general. PromiseKit is great to include in any project that does asynchronous stuff (stuff that does not execute immediately), regardless of whether or not you are using RxSwift.

[mxcl]

Closing due to stagnation.

[theladyjaye]

This might seem like a silly thing, so I definitely want the critique if it is. Seems to me that mixing the 2 provides some benefit. I know from looking at my Rx code there tends to be a lot of chaining for different streams. Sometimes though it's nice to only surface up the:

()
.then{}
.catch{}

I know you can do the something similar with Rx and mixing things is including 2 libs that overlap in functionality. But if done in a disciplined way I think there are some benefits when viewing the code:

Rx

service.register(for: registation)
.subscribe(onNext: {
    value in
},
onError: { err in

})
.addDisposableTo(disposeBag)

Promise

service.register(for: registation)
.then(
    value -> () in
}
.catch {
    err in
}

I think the Promise handling looks cleaner at the call site than the Rx version. To be sure, behind the scenes the Promise could be totally coordinated by an Rx Pipeline and resolved or rejected via onNext onError of an Observable. Maybe I'm crazy on this but aside from the added weight to the final distribution, why else am I crazy?

Obviously one of the downfalls of this is that you would get people mixing paradigms throughout a code base, which would definitely be bad. Again though, with a little discipline I think it's a problem that can be worked around.

For things like input validation etc, Rx will really shine by being exposed at the call site and provide the reader a nice way to capture what's happing to the data. On simple async calls though, I think the Promise provides a cleaner call site implementation.

Of course I could just be holding it upside down and not even know it. I'm not SUPER 100% expert at the Rx paradigm