I have a coworker who loves Ramda, he usually writes code like:
export const truncateAtWith = curry((length, callback) =>
when(
// split splitable text by checking length
propSatisfies(gt(__, length), 'length'),
// callback so render ui can be dealt by caller
pipe(trim, splitAt(length), head, callback),
),
);
Personally, this looks horrible to me because I like native JS syntax just fine, and I don’t want to go through the mental gymnastics of reading this code, as well as learning about 100 Ramda functions. Although I can’t quite get why he likes this, I know there’s a lot of people who do like ramda (and lodash, etc), so there must be a reason for it (pun intended). As a Reason person who has used these libraries, what would you tell a coworker to help them love Reason?
Note: I know Reason has automatic currying, so I bet that’s the first plus 
Note 2: I believe my co-worker believes the above code is more efficient because it’s “functional”. I don’t think that’s true because I know there’s a lot of optimization of native JS code as long as I write a pure function that does the same as this, and loading and parsing ramda library adds overhead. Can anyone smarter than me verify my hunch?
Note 3: I know there’s Rationale, which may provide some nice functions for Ramda-lovers in Reason.
There are all kinds of flavors of fp. If you want more expressivness, then try PureScript. If you want simplicty and you are doing front-end then try out Elm. But in the process you are learning a new syntax and ecosystem. Reason shines in the fact that it looks like plain JavaScript and can go even further because it has a nice foreign function interface. Additionally, many common JS libraries have been wrapped using FFI and for those JS people they will feel right at home using APIs they are most familiar with. As a by-product this makes you more productive.