
Show HN: Ferrum.js – Rust features in JS: traits and advanced iteration - sevenoftwelve
https://github.com/adobe/ferrum
======
krzkaczor
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.

~~~
Leszek
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;

~~~
nicoburns
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.

~~~
bfrydl
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'

~~~
nicoburns
But not nearly as nice as:

    
    
        match x {
            0 => 'zero',
            x if x > 0 => 'positive',
            x if x < 0 => 'negative',
        }

~~~
svrtknst
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](https://gitlab.com/svartkonst/match)

------
je42
nice README. I am a bit surprised that there is no reference to Ramda (
[https://ramdajs.com/](https://ramdajs.com/) )?

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

~~~
je42
Cool ! Thanks for pointing out those differences ! It helps when deciding on
which library is best for the use-case at hand.

------
zackify
This reminds me of a rust match function I made. It would be neat to have a
built in syntax for all of this stuff!
[https://github.com/zackify/match](https://github.com/zackify/match)

~~~
svrtknst
Nice - I did a similar thing:
[https://gitlab.com/svartkonst/match](https://gitlab.com/svartkonst/match)

Yours is pretty clever and explores a few things I thought about, too

------
kristiandupont

      // 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.

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

