> async functions create a new promise for you upon every invocation, which you resolve via `await`, but that's all invisible in the background
Is that correct? I thought async functions simply await promises. `await something()` works because something() returns a promise. But is there a promise created "invisibly" every time you invoke an async function? On Tue, Nov 7, 2017 at 2:13 PM, Naveen Chawla <naveen.c...@gmail.com> wrote: > Correct, `for..of` instead of `forEach` > > On Wed, 8 Nov 2017 at 01:21 Logan Smyth <loganfsm...@gmail.com> wrote: > >> A nit, but that would have to be `for (const move of moves) await >> doMoveAsync()` >> since the `forEach` callback is a normal function. >> >> On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla <naveen.c...@gmail.com> >> wrote: >> >>> ... that should be `await doMoveAsync()` >>> >>> On Wed, 8 Nov 2017 at 01:16 Naveen Chawla <naveen.c...@gmail.com> wrote: >>> >>>> async functions create a new promise for you upon every invocation, >>>> which you resolve via `await`, but that's all invisible in the background. >>>> It's basically: >>>> >>>> async function doMovesAsync(){ >>>> moves.forEach( >>>> move=>{ >>>> doMoveAsync(); //another async function >>>> } >>>> ); >>>> } >>>> >>>> ...so you can do regular programming, in async world. This is why I >>>> believe it's more powerful than observables, thereby making them redundant. >>>> >>>> When I say branching into multiple outputs, I do mean creating new data >>>> that leaves the original data untouched. >>>> >>>> On Tue, 7 Nov 2017 at 20:57 Michael Lewis <m...@lew42.com> wrote: >>>> >>>>> Also, if you've made it this far, I think it's worth mentioning that >>>>> these async strings are basically all you need for a realtime file system. >>>>> >>>>> File("newFile.ext").append(File("fileA"), File("fileB"), >>>>> ...).transpile().save(); >>>>> // --> automatically watches, all inputs (fileA, fileB, etc), caches >>>>> unchanged files, reapplies transforms, writes to file... >>>>> >>>>> Webpack and gulp are basically async plugin systems w/ transforms. >>>>> They're just way too complicated. >>>>> >>>>> Simplify all the things. >>>>> >>>>> And while we're at it, why not make a realtime version control >>>>> system? Not just for files, but for all the things (any data structure >>>>> inside the app). For example, if we have variable strings, could we >>>>> enable >>>>> a history on it? Instead of branching onto a separate entity/value, could >>>>> we branch *within *the string itself, so that we have an entire *verrsion >>>>> tree *for any value? >>>>> >>>>> *What are the fundamental data structures in computer science?* >>>>> The Boolean, obviously. The Integer. The String. >>>>> >>>>> Why not a realtime boolean? I suppose that's just a boolean + change >>>>> events. What is a "change event"? Just an array of functions. But >>>>> JavaScript functions are an abstract concept (compared to processor >>>>> instructions). What do functions look like at the processor level? >>>>> They're compiled with all the dependent values, right? How many processor >>>>> ticks does the average line of JavaScript use? >>>>> >>>>> I feel like all languages could boil down to a very small set of >>>>> fundamental data structures, and maybe a slightly larger set of >>>>> specialized >>>>> data structures. >>>>> >>>>> What are the different types of circuits in a process? I understand >>>>> (roughly) the basic logic gates, but is there specialized circuitry for >>>>> specialized data structures? What if those fundamental data structures >>>>> were optimized at the circuitry level? >>>>> >>>>> What if we can optimize our programs to run as nearly instantly as >>>>> possible? Most scripts are *mostly *instant - at least, there's no >>>>> external input. For any process that's *nearly* instant, couldn't it >>>>> actually be instant? In other words, 1 tick of the processor? Load up >>>>> all >>>>> the registers with the necessary values, and shine the light down those >>>>> transistors/logic gates, so that we arrive at our result, instantly? >>>>> >>>>> I really feel like this is possible. Like I mentioned earlier, I've >>>>> never compiled a lick of code in my life, and have very little >>>>> understanding of those things. But from my sense of JavaScript, it's far >>>>> from instant. How many processor ticks per line of JavaScript code, on >>>>> average? >>>>> >>>>> >>>>> >>>>> >>>>> Is anyone still listening? >>>>> >>>>> On Tue, Nov 7, 2017 at 8:47 AM, Michael Lewis <m...@lew42.com> wrote: >>>>> >>>>>> I'm not experienced in async/await enough to know what "using async >>>>>> functions to process [streams]" would look like. >>>>>> >>>>>> You would have to create a new promise for every iteration? Even if >>>>>> performance isn't an issue, it just doesn't make sense to me. It's like, >>>>>> you could use `obj.value = "my string"` instead of `var myString = "my >>>>>> string"`, and it will work. And the performance difference is >>>>>> negligible. >>>>>> But, it just doesn't make as much sense... >>>>>> >>>>>> *Branching vs Mutation* >>>>>> The point you bring up regarding "branching the stream into multiple >>>>>> outputs" is another fundamental concept in programming (that I'm still >>>>>> trying to wrap my head around). Basically, does an operation (aka a >>>>>> method) operate on the original data, or fork/branch, preserving the >>>>>> original, and creating a clone to apply the transform to. >>>>>> >>>>>> For example, arr.push() manipulates (mutates) the original array, but >>>>>> arr.slice() branches, giving you a brand new array, leaving the >>>>>> underlying >>>>>> array untouched (immutable). >>>>>> >>>>>> This has always been an area of confusion for me. Which methods are >>>>>> mutators, and which are immutable? >>>>>> >>>>>> *Async Strings* >>>>>> An interesting away to look at all this async stuff, is to consider >>>>>> strings, and their operations (methods), in an asynchronous way. How >>>>>> can a >>>>>> string be asynchronous? Just let it change over time, and broadcast >>>>>> change >>>>>> events. >>>>>> >>>>>> What if you compose a string with several pieces: >>>>>> asyncParentStr.append(asyncStrA, asyncStrB, asyncStrC). >>>>>> >>>>>> Each asyncString can have change events, and will propagate changes >>>>>> to anyone depending on it. asyncStrB.set("new value") will trigger >>>>>> asyncParentStr.change() event. >>>>>> >>>>>> I feel like this is fundamental functionality that is lacking from >>>>>> JavaScript. Now that we have `const`, shouldn't `var` automatically set >>>>>> up >>>>>> change events for that "var"? >>>>>> >>>>>> *Async transforms* >>>>>> But lets say we do asyncParentStr.append(asyncStrA, >>>>>> asyncStrB.replace("hello", "goodbye"), asyncStrC). >>>>>> >>>>>> Now we have the question: do we want this .replace() to be a "live" >>>>>> transform? When we asyncStrB.set("hello world"), does it re-apply the >>>>>> replace? I think there are many use cases for both: mutate the original >>>>>> asyncStrB, so that all references to this value also exhibit the >>>>>> transform. And also the alternative, the immutable, branching kind of >>>>>> transform, where you don't mutate the underlying value, and instead are >>>>>> branching. >>>>>> >>>>>> This concept is also the core concept of version control: do we >>>>>> continue down the same path, or branch off? >>>>>> >>>>>> *GUIs will prevail* >>>>>> You can try and create different methods ( ._replace() vs .$replace() >>>>>> ) to represent transform vs branching (I don't know which looks more like >>>>>> which). But, in the end, the GUI will prevail. Artists can dream about >>>>>> how to envision these version trees, and perfect the GUI/experience. The >>>>>> code interface just can't compete with GUI, in the long run. >>>>>> >>>>>> I suppose, its necessarily true that the API preceeds the GUI. >>>>>> >>>>>> API before GUI, but GUI all the things. That's my new motto. >>>>>> >>>>>> *What if variables were automatically async, and referential? *(As >>>>>> opposed to `const` that could be the immutable flavor) >>>>>> var str = "hello world"; >>>>>> >>>>>> str.replace("hello", "goodbye"); // transforms `str` var "in place" >>>>>> log(str) // "goodbye world" >>>>>> >>>>>> str = "hello cruel world"; // transform is reapplied >>>>>> log(str) // "goodbye cruel world" >>>>>> >>>>>> This will never happen, but it shows the fundamental difference in >>>>>> logic. Both are logical/useful... >>>>>> >>>>>> On Tue, Nov 7, 2017 at 8:08 AM, Naveen Chawla <naveen.c...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> For me the future is async functions (the present actually). I asked >>>>>>> a question about possible support for async streams / observables here: >>>>>>> https://esdiscuss.org/topic/stream-async-await and I realized that >>>>>>> my use case was much better served by just using async functions to >>>>>>> process >>>>>>> each input value in the stream. >>>>>>> >>>>>>> I think using async functions is much more powerful than >>>>>>> "observables", since it allows you to easily branch the stream off into >>>>>>> multiple outputs etc. Using Promise.all etc. is also trivial to use >>>>>>> where >>>>>>> desired, etc. >>>>>>> >>>>>>> Furthermore, async functions allow while/for loops that include >>>>>>> other async function calls, and this looks like programming with regular >>>>>>> functions, so it's trivial to set up asynchronous iteration, and/or >>>>>>> infinite event processing, etc., even without the new "async iteration" >>>>>>> proposal. >>>>>>> >>>>>>> On Tue, 7 Nov 2017 at 17:25 Michael Lewis <m...@lew42.com> wrote: >>>>>>> >>>>>>>> The email wasn't about my kids, and you don't have to read it >>>>>>>> (duh). If your time is so valuable, maybe you shouldn't be picking >>>>>>>> fights >>>>>>>> with rambling parents. >>>>>>>> >>>>>>>> Where is the list of approved topics? >>>>>>>> >>>>>>>> On Tue, Nov 7, 2017 at 5:44 AM, Bob Myers <r...@gol.com> wrote: >>>>>>>> >>>>>>>>> I'm confused. You don't have time to read "The General Theory of >>>>>>>>> Reactivity", yet (1) you have time to write this long, rambling email >>>>>>>>> about >>>>>>>>> your kids, and (2) expect people on this mailing list to spend their >>>>>>>>> valuable time reading it? >>>>>>>>> >>>>>>>>> Please stay on topic for the list. >>>>>>>>> >>>>>>>>> Bob >>>>>>>>> >>>>>>>>> On Tue, Nov 7, 2017 at 4:48 PM, Michael Lewis <m...@lew42.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Good morning JavaScript world, >>>>>>>>>> >>>>>>>>>> Maybe I'll start my mornings with a cup of coffee, and a >>>>>>>>>> discussion prompt. We'll see how long it lasts. It's 4:39am. I >>>>>>>>>> live in >>>>>>>>>> Aurora, Illinois, about an hour outside of Chicago. My kids will >>>>>>>>>> wake up >>>>>>>>>> in an hour or two, so I don't have long, and should be working on my >>>>>>>>>> framework anyway. >>>>>>>>>> >>>>>>>>>> *So much asynchrony* >>>>>>>>>> There are callbacks, promises, async/await. We have streams in >>>>>>>>>> node.js. There are libraries like RxJS for Observables (that are >>>>>>>>>> basically >>>>>>>>>> streams?). >>>>>>>>>> >>>>>>>>>> What's the end game? What will our children's children be >>>>>>>>>> learning in 100 years? Let's reduce these pieces, distilling them >>>>>>>>>> into >>>>>>>>>> their simplest components. >>>>>>>>>> >>>>>>>>>> This <https://esdiscuss.org/topic/promises-vs-streams> is an >>>>>>>>>> interesting thread (from es-discuss) regarding asynchrony, which >>>>>>>>>> references >>>>>>>>>> Kris Kowal's General Theory of Reactivity >>>>>>>>>> <https://github.com/kriskowal/gtor/>, which is too long for me >>>>>>>>>> to dig into at this point in my life. >>>>>>>>>> >>>>>>>>>> The disappointing part, is that this community (who has mastered >>>>>>>>>> asynchrony) doesn't feel like there are any shortcomings, and so we >>>>>>>>>> continue onward without fixing the mess. >>>>>>>>>> >>>>>>>>>> Oh, and generators? I don't fully understand these things. Do >>>>>>>>>> they work with promises? Can you use a generator to process a >>>>>>>>>> stream? How >>>>>>>>>> do generators work with or compare to async/await? Who knows... >>>>>>>>>> >>>>>>>>>> I think it's safe to say that asynchrony is a confusing mess. *But >>>>>>>>>> it shouldn't be. *The concept of "do it now" or "do it later" >>>>>>>>>> is as easy as 123. >>>>>>>>>> >>>>>>>>>> Recently, I read through Jake Archibald's JavaScript Promises: >>>>>>>>>> an Introduction >>>>>>>>>> <https://developers.google.com/web/fundamentals/primers/promises>. >>>>>>>>>> I really enjoy Jake Archibald's writing. He makes JavaScript less >>>>>>>>>> boring. >>>>>>>>>> But wow, understanding promises in their full depth is really >>>>>>>>>> complicated. >>>>>>>>>> Sure, a simple promise is more or less a callback, easy peasy. But >>>>>>>>>> once >>>>>>>>>> you start composing parallel and series tasks, add error handling, >>>>>>>>>> and try >>>>>>>>>> to understand the control flow - it's a lot. >>>>>>>>>> >>>>>>>>>> I feel like Promises could automatically *render a diagram *when >>>>>>>>>> using them. In Jake's very practical example (request a list of >>>>>>>>>> chapters, >>>>>>>>>> load all chapters in parallel, then append them to the page in order) >>>>>>>>>> there's a lot going on, to say the least. Wouldn't it be nice to >>>>>>>>>> see a >>>>>>>>>> diagram of these tasks? A timeline maybe? >>>>>>>>>> >>>>>>>>>> Imagine debugging a complex sequence of async actions. And you >>>>>>>>>> have no idea which piece is failing. Using the console to log >>>>>>>>>> values, and >>>>>>>>>> trying to step through the code with the debugger are two of your >>>>>>>>>> basic >>>>>>>>>> approaches. But honestly, neither of these really *show *you >>>>>>>>>> what's going on. >>>>>>>>>> >>>>>>>>>> Chrome Dev Tools has an awesome timeline GUI. I've spent an hour >>>>>>>>>> here or there tinkering with it, but can't make sense of a lot of it. >>>>>>>>>> There are 100's if not 1000's of very generic blocks that show up on >>>>>>>>>> the >>>>>>>>>> timeline, that don't clearly identify what they are. And I don't >>>>>>>>>> believe >>>>>>>>>> there's any way to visualize promises on this timeline. >>>>>>>>>> >>>>>>>>>> *The problem with Promises* >>>>>>>>>> I want to create a file system framework for node. I'd like to >>>>>>>>>> make watching the files for changes a default feature. The problem >>>>>>>>>> with >>>>>>>>>> promises, is that you can't re-resolve them. >>>>>>>>>> >>>>>>>>>> So I'm basically left with streams, or plain old callbacks. Or >>>>>>>>>> trying to recreate the promises every time they resolve... >>>>>>>>>> >>>>>>>>>> What's the end game? 100 years from now? >>>>>>>>>> >>>>>>>>>> Frankly, this is the most important question. I feel like if we >>>>>>>>>> take a step back, and try to solve these problems for the long term, >>>>>>>>>> we'd >>>>>>>>>> be better off. >>>>>>>>>> >>>>>>>>>> And so, it's 5:15. Well done, Michael. Well done. >>>>>>>>>> >>>>>>>>>> *The Future* >>>>>>>>>> If anyone has made it this far, I'm going to tell you a quick >>>>>>>>>> summary of my plan: >>>>>>>>>> >>>>>>>>>> 1. make an ultra-simple web framework (almost done?) >>>>>>>>>> 2. use that framework to make a CMS to kill WordPress >>>>>>>>>> 3. turn that CMS into a web OS that does everything a real OS >>>>>>>>>> can do, only better >>>>>>>>>> 4. turn that web OS into a real, bare metal OS >>>>>>>>>> 5. make lots of amazing (useful) software (like photoshop, >>>>>>>>>> blender, after effects, CAD, etc) >>>>>>>>>> >>>>>>>>>> Software development is sluggish. Most software is painful to >>>>>>>>>> use. Windows, Photoshop/Illustrator, many websites... Open source >>>>>>>>>> software doesn't get the funding/momentum it needs to really kill >>>>>>>>>> these >>>>>>>>>> proprietary alternatives. We need to change that. I'm going to >>>>>>>>>> change >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> Stay tuned. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> es-discuss mailing list >>>>>>>>>> es-discuss@mozilla.org >>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> es-discuss mailing list >>>>>>>> es-discuss@mozilla.org >>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>> >>>>>>> >>>>>> >>>>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >>
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss