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
carlossless [10:13]
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 map, filter etc. rather than select, where.
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.
carlossless [10:20]
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.
jspahrsummers [10:21] I guess I would rather have fewer users, but cause those users fewer problems overall. 😛