These are chat archives for ramda/ramda

Aug 2016
Aug 20 2016 14:54

quick question on ramda/ramda#1869

Why does ramda advise against using promises?

James Forbes
Aug 20 2016 16:13

I'm not sure what the official reasoning is, but here goes my interpretation.

Their not pure because they eagerly evaluate and the A+ api makes composition awkward because .then is both map and chain simultaneously.

Promise semantics are an example of the difference between easy and simple. Promises are easy to use initially but there are many ifs and buts when using the API. Meanwhile a Task or a Future is bound by Monadic laws that makes them perhaps harder to use initially but simpler in the sense their behaviour is limited to a relatively small and shared set of laws.

Simplicity leads to consistency which makes composition easier.

That said, you can use Promises with ramda without pipeP/composeP quite easily

Aug 20 2016 16:28
eh, isn't chain map and chain simultaneously?
the rest makes sense
so it's not so much "don't use promises", but more "there are other more functional methods to tackling that problem which our library will work better with instead"
Thanks so much again James
Aug 20 2016 16:33
I knee-jerked with the "we don't recommend promises" since I've grown very fond of them over the past year and a half. Bluebird in particular. My only complaint is that promises are too difficult to learn, thus using them with developers who don't develop for fun - is a challenge. To me that is a fault of their API.
Rick Medina
Aug 20 2016 21:41
What would be the "official" way to handle async stuff? you still limited to create bindings (wrapping them in tasks, composing with pipep, etc) for callbacks, promises or aync/await, right?
(wow, discovered futurize JUST atm I was writing a wrapper myself...)