carlossless [09:50] So anyone used RxSwift? I’m wondering what are your thoughts and opinions vs RAC3.
jspahrsummers [10:00] @carlossless: https://github.com/ReactiveCocoa/ReactiveCocoa/blob/07813339d3c44aa02fb1b71777baa4ede0f0f77a/README.md#how-does-reactivecocoa-relate-to-rx
Yeah, I was looking for a more practical point of view but even so. RxSwift has UI bindings, it follows the haskell naming for most transformation and composition functions
filter etc. rather than
carlossless [10:14] I find some things harder to do with RAC3 than with RAC2, and this is probably because of the standpoint _not_making_things_we_dont_want_you_to_do_easy_to_do_.
carlossless [10:15] that was a mouthful.
jspahrsummers [10:16] The patterns that are easier in RAC 2 vs. 3 are usually those patterns that:
- Confuse newcomers
- Turn off people considering RAC
- Cause unexpected difficulty down the road
jspahrsummers [10:16] My usual philosophy is: pay a marginally higher difficulty cost up-front, to avoid unexpected problems later
jspahrsummers [10:16] e.g. error handling in RAC 3 property bindings
jspahrsummers [10:17] Rx and RxSwift probably do not agree with that philosophy, in general.
My usual philosophy is: pay a marginally higher difficulty cost up-front, to avoid unexpected problems later
So isin’t this like the main reason why rac would attract seasoned developers, and shun away newcomers. Same problem Haskell probably has.
jspahrsummers [10:20] Obviously, all else being equal, it would be great to have _no_ cost now or later. But that’s rarely how API design works.
jspahrsummers [10:21] If people get “taken in” by an easy-to-use API, and then run into a shitstorm down the road, they blame it and swear it off forever.
jspahrsummers [10:21] see: Core Data, etc.
I guess I would rather have fewer users, but cause those users fewer problems overall.