[HN Gopher] Show HN: Lfi - a lazy functional sync, async, and co...
       ___________________________________________________________________
        
       Show HN: Lfi - a lazy functional sync, async, and concurrent
       iteration library
        
       Hey HN!  Roughly 4 years ago I started building a lazy functional
       iteration library for JS/TS.  I had a few goals for the library:  -
       Supporting sync, sequential async, and concurrent async iteration
       - Limiting it to a small number of orthogonal concepts that compose
       beautifully to solve problems  - Making it fully tree-shakeable  I
       built it for myself and have (mostly) been its only user as I
       refined it. I've used it in lots of personal projects and really
       enjoyed it.  I recently decided it would be nice to spread that
       enjoyment so I created a documentation website complete with a
       playground where you can try out the library.  I hope you enjoy
       using it as much as I do! Looking forward to hearing your thoughts
       :)
        
       Author : tomeraberbach
       Score  : 50 points
       Date   : 2024-12-11 20:07 UTC (1 days ago)
        
 (HTM) web link (lfi.dev)
 (TXT) w3m dump (lfi.dev)
        
       | deanebarker wrote:
       | Call me an idiot, but nowhere on the home page does it say it's
       | for JavaScript. The code samples looked like JS, but I don't know
       | every language, so I wasn't sure. It's not until I got into the
       | docs and saw "npm" was a sure we were talking about JS...
        
         | Chris2048 wrote:
         | should probably say "JS" in the title too - there are all sorts
         | of devs on HN afterall
        
         | ComputerGuru wrote:
         | I came to comment the same thing, having clicked through from
         | the link and not seen the OP's text. In my case, I searched for
         | and found the GitHub link at the bottom of the landing page and
         | saw the language in the repo details.
         | 
         | Please add "for JavaScript" to the title!
        
         | egorfine wrote:
         | > nowhere on the home page does it say it's for JavaScript
         | 
         | Yeah, and it is not mentioned in the post title. It's like JS
         | is considered the default programming language.
        
         | tomeraberbach wrote:
         | That's fair! Agreed it would be good to mention on the home
         | page :)
         | 
         | I did mention in the HN post description, but probably should
         | also say so in the title
        
           | tomeraberbach wrote:
           | Actually, looks like HN doesn't allow me to update the HN
           | title at this point. Sorry about that
        
       | WorldMaker wrote:
       | Were you aware of IxJS [0]? I've used that to good success over
       | the years. It's relationship to RxJS keeps it familiar.
       | 
       | Any thoughts on what Lfi does better/different than IxJS?
       | 
       | [0] https://github.com/ReactiveX/IxJS
        
         | tomeraberbach wrote:
         | I was not aware of it!
         | 
         | As far as I can tell, it has some similar ideas (and seems
         | pretty nice!), but I noticed the following differences:
         | 
         | - I don't _think_ it supports "concurrent" iteration [1]
         | 
         | - It doesn't have a "reducer" concept with composition and what
         | not [2]
         | 
         | - It doesn't have a concept of "optionals" [3]
         | 
         | [1] https://lfi.dev/docs/concepts/concurrent-iterable
         | 
         | [2] https://lfi.dev/docs/concepts/reducer
         | 
         | [3] https://lfi.dev/docs/concepts/optional
        
           | WorldMaker wrote:
           | > I don't _think_ it supports "concurrent" iteration
           | 
           | I believe what you are calling a "concurrent" iteration is
           | one of the use cases for Observables, so would be on the RxJS
           | side (the "parent" project).
           | 
           | > It doesn't have a "reducer" concept with composition and
           | what not
           | 
           | Interesting. I'll read further on what you are doing there.
           | Seems possibly similar to Lenses/Prisms in FP, with different
           | rules.
           | 
           | > It doesn't have a concept of "optionals"
           | 
           | Good point. So far I've not found a JS approach to optionals
           | I'm entirely happy with. I've had some suggest I should give
           | Effect [0] a deeper look, but given I'm mostly happy with
           | RxJS the bulk of Effect doesn't appeal to me. The dual of an
           | Option being an iterator with 0 or 1 values is something I've
           | seen before and something to keep in mind.
           | 
           | [0] https://effect.website/docs/data-types/option/
        
             | tomeraberbach wrote:
             | > I believe what you are calling a "concurrent" iteration
             | is one of the use cases for Observables, so would be on the
             | RxJS side (the "parent" project).
             | 
             | Ah, got it. I don't think I quite understood the
             | relationship between this project and RxJS. I did know
             | about RxJS's observables, yes. I do sort of hint at the
             | relationship between concurrent iterables and the
             | observables [1], but I tried to make concurrent iterables a
             | bit more specialized to what you'd normally use an iterable
             | for.
             | 
             | > Interesting. I'll read further on what you are doing
             | there. Seems possibly similar to Lenses/Prisms in FP, with
             | different rules.
             | 
             | I think I've heard of lenses (but not prisms), but don't
             | think I ever actually learned what they are. Would be
             | curious if you find a connection between those and my
             | reducers :)
             | 
             | > Good point. So far I've not found a JS approach to
             | optionals I'm entirely happy with. I've had some suggest I
             | should give Effect [0] a deeper look, but given I'm mostly
             | happy with RxJS the bulk of Effect doesn't appeal to me.
             | The dual of an Option being an iterator with 0 or 1 values
             | is something I've seen before and something to keep in
             | mind.
             | 
             | Yeah, I liked representing optionals as iterables because
             | you get a lot of functionality for "free" [2]
             | 
             | [1] https://lfi.dev/docs/concepts/concurrent-
             | iterable#:~:text=A%....
             | 
             | [2] https://lfi.dev/docs/concepts/optional#why-use-
             | iterables-to-...
        
               | WorldMaker wrote:
               | Prisms are Lenses through Options. They compose very
               | similarly to Lenses and it is easy to convert a Lens to a
               | Prism to compose Prisms from existing Lenses. Every Lens
               | is a very simple "degenerate" Reducer (a Lens is just a
               | getter and a setter from one "state" to another), but
               | Prisms feel even more like "real" Reducers because of the
               | optional states that can be involved. So Prisms and
               | Lenses are very common composable Reducers in some styles
               | of FP.
        
       | stevedekorte wrote:
       | Looks useful and powerful. Nice work!
        
         | tomeraberbach wrote:
         | Thank you!
        
       | uwemaurer wrote:
       | great library! I just tried it out and compared it with iter-
       | tools
       | 
       | I like Lfi better, great documentation!
       | 
       | Here is the example I use to compare:
       | https://stackblitz.com/edit/stackblitz-starters-ia9ujg6m?fil...
        
       ___________________________________________________________________
       (page generated 2024-12-12 23:01 UTC)