And no, I don't think that `do expressions` proposal is really great solution.
Exactly this. I generally get met with skepticism when talking about Rust for web dev, because so many people say "you don't need that performance" (which is itself pretty arguable if one cares at all about energy footprint), but it isn't just the performance that makes Rust such an attractive option.
Technically still on vocation so I added a ticket to update the Readme :)
I've taken a look at Ramda! It does look very nice; I think the goals of Ferrum and Rambda are a bit different: Rambda seems to aim at being a kind of FP standard library for JS so in that regard it is more comprehensive than Ferrum.
Ferrum on the other hand is primarily designed to introduce some new features for iteration libraries in JS: Reverse Currying, Objects as Sequences and Lazyness are not provided by Rambda. Both Rambda and Ferrum feature a `pipe()` function.
Also Ferrum provides a Traits and a standard library of traits like Eq, Rambda does not I think :)
So I would prefer using Ferrum/Sequence over the list transformation functions from rambda because of the above mentioned features, but that shouldn't stop anyone from using the rest of Rambda (or even underscore or lodash); you should be able to mix and match functions from rambda and ferrum without any issue; even in the pipe functions; so I would say use Ferrum/Trait and Ferrum/Sequence and keep using Rambda for the rest because it's great; I think I'll add another example for mixing Ferrum and Rambda and Lodash :)
Yours is pretty clever and explores a few things I thought about, too
// This is not very handy because you might need to scroll down to find the last
// argument; you will also need to scroll down to determine whether the call to
// each is using currying
Unfortunately most JS code I work with is not written in such a functional style, so function bodys very often become larger than a couple of lines and in these cases having to search the argument somewhere a couple lines down does break the flow for me a bit…
It's the least problematic trade off I could find so far, trying to marry FP and procedural JS dev styles :)