41–50 of 51 posts
How does this compare to Effect, or Fluture? There have been so many attempts at improving these things in JS that it's hard to keep track.
easy differences: Effect does everything and is huge, this does iteration only and is tiny
I think it just has completely different goals. Read through the home page examples and getting started and you'll see it's pretty different.
I don't understand (but am open to be persuaded), isn't iteration in js now trivially easy and actually quite powerful? Especially since we can now put 'await' everywhere? What are the killer use cases for this lib?
- Some people like/prefer writing iteration in a functional style, which this library enables
- It's pretty easy to create unintentional async/concurrency bottlenecks with the simple `Promise.all` approach (see the home page example)
Interesting. How is the concurrency achieved? I don’t see any info about concurrency implementation on the website
Recommend reading it all, but this part is probably most useful: https://lfi.dev/docs/concepts/concurrent-iterable#how-does-i...
I'm not sure I know the use case for all of this logical complexity. Is there a specific use-case you had in mind? Split the array of elements to process. Set up a promise.all against a function that handles sync/async function calls against each chunk and accumulates an array of results. This isn't the end of the world for any of the practical use cases I can think of. The efficiency loss and memory consumption is m…
pipe and map are too complex for "ECMAScript devs?" give me a break! > should be ported to WASM valid.
I'm not sure I know the use case for all of this logical complexity. Is there a specific use-case you had in mind? Split the array of elements to process. Set up a promise.all against a function that handles sync/async function calls against each chunk and accumulates an array of results. This isn't the end of the world for any of the practical use cases I can think of. The efficiency loss and memory consumption is m…
To clarify, the point of it isn't _just_ performance. It's a combination for writing the iteration code in a functional style, which some people like/prefer, while retaining certain performance characteristics that you'd get from writing more imperative code. For example, the "naive" approach to functional programming + concurrency results in some unintentional bottlenecks (see the concurrent iteration example on the…
And the third examples are much easier to maintain with a simple function I drafted up for sake of argument `processArrayWithStages(array: T[], limit: number, stages: Array Promise>)`
In my experience, unless you're doing math in promises which I would recommend shifting to WASM, you're not going to feel the overhead of these intermediary arrays at scales that you shouldn't be in WASM already (meaning over several millions of entries).
The amazing people and teams working on V8 have done well to optimize these flows in the past four years because they are extremely common in popular applications. Strings aren't even copied in the sense you might think, you have a pointer to a chunk that can be extended and overwritten which incurs a penalty but saves tons of RAM.
processArrayWithStages: https://gist.github.com/DevBrent/0ee8d6bbd0517223ac1f95d952b...
Earlier quoted context omitted.
pipe and map are too complex for "ECMAScript devs?" give me a break! > should be ported to WASM valid.
Node.js pipe and map are standard implementations most developers understand. I do not know what these strange implementations are from this library. They do not make sense to me. That's what I mean. Why learn 3 different meanings of pipe? I already have to learn too many meanings of pipe across multiple environments and languages. I do not need more pipe and map meanings within javascript.
Edit: I'll further reveal my ignorance. What's the function piping API in node? Is it in the browser? Does work like the pipe operator |> in R, Elixir, and F#?
Another fp-ts
I'm somewhat familiar with fp-ts, and I think lfi is pretty different. fp-ts seems more focused on "pure" functional programming in the style of languages like Haskell. It's much more opinionated on how you should write your code, including the data structures you should use. Plus, it's not really concerned with concurrency in the way that lfi is. I think lfi is a lot less invasive/opinionated on how you write your c…
Interesting. How is the concurrency achieved? I don’t see any info about concurrency implementation on the website
Some info on this page: https://lfi.dev/docs/concepts/concurrent-iterable Recommend reading it all, but this part is probably most useful: https://lfi.dev/docs/concepts/concurrent-iterable#how-does-i...
One function I've written that I frequently use is a generic iterate function which (in JS/TS land) allows you to loop over a T[], Array, ArrayLike, Iterable, AsyncIterable, including generators and async generators.
It is just easier to always be able to write: "for await (const item of iterate(iterable))" in most places, without worrying about the type of the item I am looping over.
I like the reducers and collectors in your library! Going to try it out.
Also, something new I discovered is the Array.fromAsync() method in JS, which is like Array.from() but for async values. I don't think it is available in all browsers/runtimes yet though.