17 comments

[ 2.8 ms ] story [ 50.9 ms ] thread
nice README. I am a bit surprised that there is no reference to Ramda ( https://ramdajs.com/ )?
Thanks for the tip!

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 :)

Cool ! Thanks for pointing out those differences ! It helps when deciding on which library is best for the use-case at hand.
another day, another rust article. rust slogan; more press articles than applications.

readers of sites like this get a slanted view of industry.

On a language level, I miss how many statements became expressions in Rust. For example, I would really love to `if` be an expression in JavaScript. This makes a language so much more expressive.

And no, I don't think that `do expressions` proposal is really great solution.

You want a conditional expression in JavaScript ? you could use the ternary operator : you don't have to use it if you don't want to though;
Ternary operator don't nest very nicely though (they do nest , but it's not very readable). IMO a bigger difference is Rust's match and blocks also being expressions. These have no alternatives in JavaScript.
Nesting multiple branches of ternary operators doesn't work well but if it's a sort of “if elseif elseif else” situation I think this looks pretty nice:

    x > 0 ? 'positive' :
    x < 0 ? 'negative' :
    'zero'
But not nearly as nice as:

    match x {
        0 => 'zero',
        x if x > 0 => 'positive',
        x if x < 0 => 'negative',
    }
I actually made a library for that!

It's published on npm and everything. It's small, a bit unpolished, maybe needs more docs, but it works pretty damn well if you ask me!

https://gitlab.com/svartkonst/match

Agreed. There are so many nice little touches in Rust that having nothing to do with it's "safe + low-level" USP. I would love to see a Rust-style language (expression orientation and rust-style enums being top of my wish list) in the javascript/python/ruby/php niche.
> There are so many nice little touches in Rust that having nothing to do with it's "safe + low-level" USP.

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.

  // 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
..only if your applied function is more than a page tall, which it probably isn't if it's inline? I think Ramda gets this right and yes, there are a few times where the order seems a bit less aesthetic but it feels more correct to me.
I do get where you are coming from and I do have to admit that even to me the entire reverse currying seems kind of alien…especially as someone coming from a very functional style where functions stay very short…

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 :)