Merge with iter-tools?

[conartist6]

Just curious to hear what the reactions to this might be. I'm the maintainer of iter-tools, and I've put quite a lot of work into it. It has a level of polish that I think ix lacks, but I suspect that ix has many more users/usages.

Let me go into a little more detail. iter-tools has full API documentation and 99% test coverage. It has universal testing invariants, e.g. any test will fail if the iterator is not appropriately cleaned up. It has sync/async API parity, and a novel but rapidly maturing methodology for coding in a way that allows that parity to be maintained in a way that keeps devs sane. I would also say that iter-tools is packaged better -- it's at least 7 times smaller than ix while supporting (afaik) the same basic use cases.

Both libraries have some unique and useful APIs, so the API made by combining the two would be truly best-in-class. iter-tools has more abstract operations over all iterables, and ix has more integrative operations.

What I suspect about usage comes largely from github. Github shows iter-tools used in 3 repos, whereas ix shows up in package.json in 232 repos.

[trxcllnt]

Ix is largely a port of .NET's System.Interactive package (@mattpodwysocki was a member of the LINQ team), making it the iterable (and async-iterable) dual to RxJS.

The motivations to this point have been to maintain duality with Rx and faithfully port System.Interactive to idiomatic TS/JS, but it's definitely time to start evolving it in a more performance-oriented direction (something I greatly admire about iter-tools :slightly_smiling_face:). Neither of us work on it full time anymore, so finding the time to do that has been difficult.

I would also say that iter-tools is packaged better -- it's at least 7 times smaller than ix while supporting (afaik) the same basic use cases.

You're probably looking at the main ix package, which bundles all the ESNEXT CJS/ESM/UMD and ES5 UMD (plus typings + sourcemaps) into one big package. This is purely for convenience, and because disk space is cheap. Because predicting everything about library consumers build toolchains is impossible, we also publish individual targets under the @reactivex/ix-* namespace for more specialized or disk-conscious consumers.

[conartist6]

Somehow I never saw this. Thanks for the background on the project and its maintainers! I've also been finding it difficult to summon the time and energy to do the work I've planned for iter-tools, which is one of the main reasons I'm interested in seeking out more collaboration.

I'm ashamed to admit that I don't know very much about how iter-tools perf holds up in the wild. I know it has some unique abilities in the JS ecosystem like the ability to split infinite iterables. I have made some significant steps on constant-factor performance improvements such as centralizing any code I can (so it gets hot faster) and attempting to maintain monomorphism across the library, but there are still many more ideas I want to test and implement.

[conartist6]

You might not wish to close this as completed, but rather as not planned