What does HackerNews think of proposal-iterator-helpers?

Very much agreed. The amount of mileage we get from using Spread (literally the ...) alone has been amazing. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Iteration helpers is shipping soon, that'll be a huge help (async iteration helpers will be delayed for a while). https://github.com/tc39/proposal-iterator-helpers .

In the olden days, I feel like the codebases I worked on needed to use .apply() multiple times a week, to figure out some creative way of invoking functions. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... That's all gone now; I'd take even odds that 50% of my team knows .call and .apply.

Chrome 117 is shipping Object.groupBy() and that's gonna be a huge help in eliminating a lot of the last places we end up using lodash. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

There are now builtin iterator versions of most of these looped functions [1], should be shipping in stable Chrome next month. The "give me an array at the end" function is spelled toArray.

But it's not going to help all that much with this problem. The iterator protocol in JS involves an allocation for every individual value, and while in some cases that can be optimized out, it's pretty tricky to completely optimize.

It's always going to be difficult to beat a c-style for loop for performance.

[1] https://github.com/tc39/proposal-iterator-helpers/

> focus more on improving the terrible JS web API

That's W3C’s job, not ECMA’s.

> Where are all the containers?

?

> Sorted sets/maps?

Sets and Maps are sorted (by insertion order)

> Why can't I even map an iterator?

It's coming, but someone will likely be exhausted by that addition. https://github.com/tc39/proposal-iterator-helpers

I often miss map, reduce and filter on iterators, though this is already a stage 2 proposal: https://github.com/tc39/proposal-iterator-helpers.

Mainly pushing proposals like https://github.com/tc39/proposal-iterator-helpers that make it easier to work with (async) iterators.

According to the TC39 ECMA262’s repo [1] (ECMA262 is a committee responsible for planning and creating new syntax that goes into JavaScript) Observables haven’t been brought up at a meeting in over three years and they are still at stage one of the four stage process. I’m not saying there’s not hope I’m just wondering if it will end up happening. Either way I’m fine with or without Observables as async iterators, Node streams, and WHATWG streams are already pretty powerful. In fact the creator of RxJS made a library based off iterators called IxJS that looks interesting and hopefully eventually iterators in JS will have iterator helpers [2] where you can chain things off of them (currently stage two and last talked about last year). Also another thing to keep your eye on in the standards process could possibly be emitter [3] it’s also stage 1 (like Observable) but was talked about last year as a kind of push based replacement for Subjects in RxJS/Observable land.

[1]: https://github.com/tc39/proposals/blob/master/stage-1-propos...

[2]: https://github.com/tc39/proposal-iterator-helpers

[3]: https://github.com/tc39/notes/blob/master/meetings/2019-06/j...

the a:b notation for JS is still in proposal phase https://github.com/tc39/proposal-slice-notation/pull/32, but I'll use it below to create ranges

I don't understand your `+0.5`, I've written below the transcription for your description

    [...1:30].map(a => 
      [...a+1:30].filter(b => gcd(a,b)==1).map(b => 
        [...b+1:30].filter(c => gcd(a,c)==1
          && gcd(b,c)==1 
          && Number.isInteger((a**3+b**3+c**3)**(1/3))
        .map(c => [a, b, c])
      )
    ).flat(2)

Or another equivalent way:

    [...1:30].flatMap(a => 
      [...a+1:30].filter(b => gcd(a,b)==1).flatMap(b => 
        [...b+1:30].filter(c => gcd(a,c)==1 
          && gcd(b,c)==1 
          && Number.isInteger((a**3+b**3+c**3)**(1/3)))
        .flatMap(c => [[a, b, c]])

Or another way (generating first all the triples):

    [...1:30].flatMap(a => [...a+1:30].flatMap(b => [...b+1:30].flatMap(c => [[a, b, c]])))
      .filter(([a, b, c]) => gcd(a,b)==1 && gcd(a,c)==1
                          && gcd(b,c)==1 && Number.isInteger((a**3+b**3+c**3)**(1/3)))

with https://github.com/tc39/proposal-iterator-helpers, which would allow lazy evaluation, and make more sense than above

    (1:30).flatMap(a => (a+1:30).flatMap(b => (b+1:30).flatMap(c => [[a, b, c]])))
      .filter(([a, b, c]) => gcd(a,b)==1 && gcd(a,c)==1
                          && gcd(b,c)==1 && Number.isInteger((a**3+b**3+c**3)**(1/3)))

without the slice-notation, it's really ugly (hence the proposal in the first link)

    Array.from({length: 30},(_,a)=>a+1)
      .flatMap(a=>Array.from({length: 30-a-1},(_,b)=>a+b+1)
        .flatMap(b => Array.from({length: 30-b-1},(_,c)=>b+c+1).flatMap(c => [[a, b, c]])))
    .filter(([a, b, c]) => gcd(a,b)==1 && gcd(a,c)==1
                          && gcd(b,c)==1 && Number.isInteger((a**3+b**3+c**3)**(1/3)))

We're getting there. I made both node and web streams into async iterables, and have now proposed this for js standardisation: https://github.com/tc39/proposal-iterator-helpers