I'm gonna have to watch this several more times to actually grok it, but seems incredibly powerful! Just started really learning generators recently, so this is perfect timing.
I really loved how observables solve some data flow problems and I'm looking forward to see how things will be with delimited continuation. Great lecture and I will pay attention to the news ❤
Great talk! I would really like to also have EffectTS related content on this great channel. EffectTS is also about delimited continuations with great developer experience.
@@MichiganTypeScript No, not directly, just the usual suspects appearing on their youtube channel :). A fully recorded workshop and deep QA session would be amazing!
Eric Bower is a software engineer working out of Ann Arbor, Michigan. When he's not running/longboarding/building keyboards/spending time with family, he likes to push the boundaries of TypeScript, particularly when it comes to utilizing generators. He's worked on redux-saga and is the creator of saga-query. You might know him for his project neovimcraft.com, or maybe you've seen his blog (bower.sh ) come up on Hacker News. Check out his GitHub (github.com/neurosnap ) to see more of his open-source projects.
@@MichiganTypeScript The questions around the developer experience, the debugging (if you are not using Vite), 1st class TypeScript support, the appropriate testing paradigm that avoids testing implementation - all need very clear answers. Speaking from experience, it’s extraordinarily difficult to push for the adoption of this technology given the added layer of complexity and ambiguity. This is perhaps a problem of education, in simple terms: "how do you do this correctly?" and "what is happening under the covers?"
@@zavarka2 these are great conversations to take to the MiTS Discord. we talk about this kind of stuff all the time there. Also, selfishly, it'd be cool to hear more about the experience you're drawing from on this topic. Not all too many people working on this specific space.
@@MichiganTypeScript Approximately two years ago, I convinced my company to adopt Redux-Saga for a React-based customer portal app. The primary benefit I saw in Redux-Saga and generators was the ability to explicitly define the application's state machine, an aspect that typically remains obscure. We successfully implemented nearly a hundred complex business rules and coordinated them with OAuth and SAML to ensure that no illegal state transitions could occur, despite heavy concurrency and potential race conditions. Redux-Saga simplified the process for us. It is a beautifully crafted paradigm, and it has been performing outstandingly, ticking like a Swiss clock. Recently, we attempted to replace Redux-Saga with XState, attracted by its impressive graphical tooling for authoring and inspecting state machines. However, in the end, we agreed that Redux-Saga is still the best choice for our application due to the ease with which it lets us compose effects in complex choreography. I think this is a critical aspect of generators and effects libraries that many developers overlook, often opting for conventional imperative approaches. Thank you for recommending MiTS Discord!
Could one argue that react hooks are implemented under the hood using delimited continuation? It seems really similar to me. A component being an evaluate call, and each call to a hook is a shift.
That's a very interesting idea.. like the mental model for understanding React was hard enough in the `this.setState` days. These days, it's even harder to fit it all in one brain.
I feel like this talk would’ve benefited from explaining delimited continuations without jumping straight into JavaScript code. The talk by Alexis King is a better introduction. ua-cam.com/video/TE48LsgVlIU/v-deo.htmlsi=yH4gcMcL8M8_vjRI Also, it is a bit disingenious to call delimited continuations a “brand new paradigm”. They have been around in literature, and in various Schemes for at least 30 years.
Great feedback! Any more talks on the topic are super appreciated by all! Totally get what you're saying regarding the paradigm being older. The other side of the coin is that it's something that's still pretty foreign to most developers so it's new in that sense. e.g. Caitie McCaffrey has a really fantastic talk from 8 years ago on "the Saga pattern" and although (as she pointed out in the talk) the pattern itself has very old roots there are near zero modern day implementations (well at least there were at the time: she doesn't even mention redux-saga).
I wanted to see how an async code looks like with and without delimited continuations (DC). But that's what eventually matters to me, because based on that, I can decide whether DC is beneficial to the end programmers or not. I mean, why should we learn DC in the first place? Is there any justification shown in this video? I didn't see any.
the main selling factor is that you can treat sync and async code literally the same. now.. granted.. for some kind of products this isn't as important as it sounds but for others it's a big win. for that second group, DC is a better fit.
@anTypeScript Yes. I heard in the beginning itself that DC allows us to write sync and async code in the same way. All functions become the same color. However, what I'm missing in this video is, a complex async code, which then is converted into DC-fied code. I wanted to see it for comparison. That is missing, hence the claim stays a claim, especially because the keywords async/await makes the async code a lot simpler. What else DC could do, is a mystery!
@@sirnawaz if that's what you crave then you should come on the MiTS discord! Eric is active there and also his project (starfx (under neurosnap/starfx on GitHub)) has some examples if memory serves correctly.
@@sirnawaz the person who wrote the async library in common lisp had a comment somewhere how he really wished common lisp had continuations as it would have made his code a lot simpler.
I'm gonna have to watch this several more times to actually grok it, but seems incredibly powerful! Just started really learning generators recently, so this is perfect timing.
those of us that were there in person were all fuzzy-in-the-head for hours afterwards. don't worry! haha
I really loved how observables solve some data flow problems and I'm looking forward to see how things will be with delimited continuation. Great lecture and I will pay attention to the news ❤
we might be having Eric back to do a showcase on starfx some time soon, so be on the lookout!
Great talk! I would really like to also have EffectTS related content on this great channel. EffectTS is also about delimited continuations with great developer experience.
that's a great reminder to follow up with them! do you know anyone working on EffectTS?
@@MichiganTypeScript No, not directly, just the usual suspects appearing on their youtube channel :). A fully recorded workshop and deep QA session would be amazing!
@@haydermabood cool. it's on our list (which, admittedly is quite long, heh.)!
Eric Bower is a software engineer working out of Ann Arbor, Michigan. When he's not running/longboarding/building keyboards/spending time with family, he likes to push the boundaries of TypeScript, particularly when it comes to utilizing generators. He's worked on redux-saga and is the creator of saga-query. You might know him for his project neovimcraft.com, or maybe you've seen his blog (bower.sh ) come up on Hacker News. Check out his GitHub (github.com/neurosnap ) to see more of his open-source projects.
A very good talk, but some concerns raised in the Q&A have yet to be addressed.
such as?
@@MichiganTypeScript The questions around the developer experience, the debugging (if you are not using Vite), 1st class TypeScript support, the appropriate testing paradigm that avoids testing implementation - all need very clear answers. Speaking from experience, it’s extraordinarily difficult to push for the adoption of this technology given the added layer of complexity and ambiguity. This is perhaps a problem of education, in simple terms: "how do you do this correctly?" and "what is happening under the covers?"
@@zavarka2 these are great conversations to take to the MiTS Discord. we talk about this kind of stuff all the time there.
Also, selfishly, it'd be cool to hear more about the experience you're drawing from on this topic. Not all too many people working on this specific space.
@@MichiganTypeScript Approximately two years ago, I convinced my company to adopt Redux-Saga for a React-based customer portal app. The primary benefit I saw in Redux-Saga and generators was the ability to explicitly define the application's state machine, an aspect that typically remains obscure. We successfully implemented nearly a hundred complex business rules and coordinated them with OAuth and SAML to ensure that no illegal state transitions could occur, despite heavy concurrency and potential race conditions. Redux-Saga simplified the process for us. It is a beautifully crafted paradigm, and it has been performing outstandingly, ticking like a Swiss clock. Recently, we attempted to replace Redux-Saga with XState, attracted by its impressive graphical tooling for authoring and inspecting state machines. However, in the end, we agreed that Redux-Saga is still the best choice for our application due to the ease with which it lets us compose effects in complex choreography. I think this is a critical aspect of generators and effects libraries that many developers overlook, often opting for conventional imperative approaches.
Thank you for recommending MiTS Discord!
Could one argue that react hooks are implemented under the hood using delimited continuation? It seems really similar to me. A component being an evaluate call, and each call to a hook is a shift.
That's a very interesting idea.. like the mental model for understanding React was hard enough in the `this.setState` days. These days, it's even harder to fit it all in one brain.
What are the performance implication of this?
check out the Michigan TypeScript discord (in the video description) and come talk to Eric about it! :)
this talk has a really weird, sort of artificial feeling, atmosphere.
we always love feedback like this: can you say a little more on what you mean?
Definitely a bit cringe.
@@proweiqican you be specific? definitely interested to know what you mean
@@MichiganTypeScript sorry, i dont know what made it feel this way for me. I would not call it cringe through, that's not an issue
@@blacky7801 no worries! if you have any feedback like this in the future we're always happy to hear it! thanks!
I feel like this talk would’ve benefited from explaining delimited continuations without jumping straight into JavaScript code. The talk by Alexis King is a better introduction. ua-cam.com/video/TE48LsgVlIU/v-deo.htmlsi=yH4gcMcL8M8_vjRI
Also, it is a bit disingenious to call delimited continuations a “brand new paradigm”. They have been around in literature, and in various Schemes for at least 30 years.
Great feedback! Any more talks on the topic are super appreciated by all! Totally get what you're saying regarding the paradigm being older. The other side of the coin is that it's something that's still pretty foreign to most developers so it's new in that sense. e.g. Caitie McCaffrey has a really fantastic talk from 8 years ago on "the Saga pattern" and although (as she pointed out in the talk) the pattern itself has very old roots there are near zero modern day implementations (well at least there were at the time: she doesn't even mention redux-saga).
Nothing worse than redux-saga :/
have you tried redux-observable?
For finite state machines, Redux-Saga is hard to replace, if your app is complex.
I wanted to see how an async code looks like with and without delimited continuations (DC). But that's what eventually matters to me, because based on that, I can decide whether DC is beneficial to the end programmers or not. I mean, why should we learn DC in the first place? Is there any justification shown in this video? I didn't see any.
the main selling factor is that you can treat sync and async code literally the same. now.. granted.. for some kind of products this isn't as important as it sounds but for others it's a big win. for that second group, DC is a better fit.
@anTypeScript Yes. I heard in the beginning itself that DC allows us to write sync and async code in the same way. All functions become the same color. However, what I'm missing in this video is, a complex async code, which then is converted into DC-fied code. I wanted to see it for comparison. That is missing, hence the claim stays a claim, especially because the keywords async/await makes the async code a lot simpler. What else DC could do, is a mystery!
@@sirnawaz if that's what you crave then you should come on the MiTS discord! Eric is active there and also his project (starfx (under neurosnap/starfx on GitHub)) has some examples if memory serves correctly.
@@sirnawaz the person who wrote the async library in common lisp had a comment somewhere how he really wished common lisp had continuations as it would have made his code a lot simpler.