 All right, let me get things started. Good morning, bonjour. You saw my keynote. You know that my French, it's not so good. So I will keep it to a minimum. Merci, thanks for coming this early in the morning to hear about promises in NodeCore. I haven't had the chance to have breakfast yet, so I hope that you all are doing all right and I'm prepared to dive in. I'll start off by saying happy birthday to Node again. This is 10 years. Node was announced in 2009. Excuse me. Ryan Dahl talked about it at JSConf EU in 2009. It was pretty exciting. I remember that those days. If somebody can decipher that for me, I think it says happy birthday or something along the lines. That might take a while, so we'll move on. So yeah, I'm here to talk to you about core APIs in Node and what state they're in in terms of being thenable, promise-ified. So you can't have a conversation online or in person about promises without puns. But I'm going to do my best here to keep puns to an absolute minimum. I realize that is a pun, so let's market zero, start from there. I know some of you folks out there, but for the people who I don't know, my name is Joe Seppi. I am an open source engineer at a little startup called IBM. As you can tell by the photo, IBM has been around for a little bit of a while. Over 100 years, which always kind of shocks me when I realize that. And remember that Apple and Microsoft or what, the 80s or something. We were 1911. IBM has nothing to do with HAL. People noticed that it's one letter off, IBM, HAL. That was just a coincidence, setting the record straight here. So yeah, anyway. I wanted to bring my family because Montreal is awesome, but they couldn't make it. I'm just kidding. That's not my family. That's my family. I'm just kidding. That's my band. I play in a couple of bands. That's my punk band. That's my improv metal band. These are actually friends of mine in a band called Built to Spill. That's not Sam Roberts down in the corner. That's the drummer of Built to Spill, but kind of looks a little bit like him, right? Sam's a Nodecore collaborator. So yeah, I was also in a Misfits cover band. So I thought I'd wear my shirt today. I realized when I was going through my slides that I actually brought this shirt with me. So if you're into Misfits, come talk to me later. Speaking of talking to me later. Oh, wrong slide. If there's, that one's from JSConfU. If there's karaoke tonight, definitely give me a holler. It's kind of a tradition. Okay, so enough of my digressions. Actually, maybe this is kind of a little bit more of digressing as well. So my personal context with promises is when I used to work at The New York Times a while ago, back in 2012, I started doing a weekly JavaScript lunch and learn that was internal. Every Thursday we'd get together at noon and bring our lunches in a meeting room and usually be like 10 to 20 people there. It actually, I did it weekly for over a year and only missed a couple of weeks. And it was largely, the presenters were largely internal folks at The New York Times. And it was a lot of fun. I suggest if you have a company that you're able to do that, it's a great way to get people together and talk about tech. We did have a couple of external folks come in. We had Tom Hughes Croucher came and chatted with us, Rebecca Murphy, Spike Brem, and Dominic DiNicola. So Tom came and talked about Sockets and Streams. And again, this is in 2012. This is Tom, Tom's one of the original node collaborators in the early days. So he came and talked to us about Sockets and Streams, which was pretty exciting. And Rebecca came and talked to us about a bunch of things, including Yequery. Has anybody here ever even heard of Yequery? No. That's amazing. So I recommend you Google Yequery. That's Paul Irish, Rebecca Murphy, Adam Sontag, and Alex Sexton. They did a podcast on Yequery and other related JavaScript technologies a while ago. But it was a lot of fun. Spike came and talked to us about Render, which was a way to build isomorphic JavaScript applications using Backbone and Node. And it was pretty exciting at the time. Again, this is 2012. Miles was talking about Universal JavaScript yesterday morning. And I think the joke was that he was like bringing back 10 years ago or something. And I really related to that because of, you know, these conversations we're having them. And Dominic was working on the Promises A plus spec at the time, which was the, you know, is the spec for how to implement promises. And so it was, it was, it was pretty exciting times. I even wrote on the New York Times website about Dominic coming in and talking to us and about the problems of the Async Nightmares, the callback hell. So I actually am a published New York Times writer. That's on my resume. Not really. So yeah, we were, we were fighting callback hell back then. Still, still are sometimes. And then I went and worked at Behance, which was acquired by Adobe. That's Frankie the dog. He looks cute, but he's really serious about business. You can tell by the tie. Christian looks crazy, but he's also serious about business. But when I got to Behance, everything was promissified. And that was kind of new for me, like all in whole hog, everything we were writing was, you know, just about everything was, was, was thenable. And so I had to, you know, really ramp up and, and, and it was kind of like a mind shift, you know. But again, this was, this was a while ago. Recently, Ryan went back to JS ConfU last year and had this real click baity talk, 10 things I regret about Node.js, which was his way of introducing Dino. But he brought up a lot of good points, things that he had learned from, from writing Node. And one of them was regretting taking promises out of Node in the early days. As you can see up there, he says, I added promises to Node in June 2009, but foolishly removed them in February 2010. He does go on to say that perhaps moving, removing them was a good idea because it allowed the community to work on the problem and flesh out something that worked better for, for the community. There are a number of libraries that would implement promises in different ways and it kind of helped inform, you know, where, where we ended up landing and where we are today. But he also says, nodes, many async APIs are aging badly because of this. And I'm not sure if this was, I assume this was out of the talk, but there was a bit of Twitter conversation going on after that. You know, lol at Node.js core modules for still using the callback pattern. There are lots of lols there. But as usual, Myles comes to the rescue and points out that a couple of the core APIs are actually promissified, including, in this example, FS. And people were like, huh, what? So he points out that FS and DNS have an experimental promise API. I don't think that's, this was a little over a year ago, so that's not, that's fully in there. And then, of course, you can see in the bottom there, the puns are raging. You can't get away from them when you're talking about promises. And then, you know, Sam points out that we have this promisify utility that you can use to, to wrap APIs in, you know, a Venable if, if, if it's possible. I wouldn't recommend doing it on all of them. So I was talking to Matteo about this a few months ago, and he described it this way, that it's an insanely hard problem that's been there forever, and that we've never been able to actually solve, like fully solve. We're working on it, but it's taking time. So the big problem is, promises was designed for browsers. The spec was designed for browsers and failing, if you have a failing promise, it only affects one person, right? You know, in a browser, your unhandled rejection crashes your browser and, you know, it's just one person. It's not a whole, a whole web app. So if, if you have a failing promise in Node, it takes down the whole server. And so that affects a lot more than one person and their, their, their browser tab. So if we look at an example of how this can happen, we have a promise set up here. And it's immediately resolves, but there's some JavaScript happening after that. And we may never know, you know, if stuff fails in some function call or, or what, we don't really have access to that. And in this example too, the program ends and we have no way to get the promises that have never settled. So there are a couple of challenges there that really creates essentially a debugging nightmare. There's been some progress, so zero cost async stack traces shipped a little while ago in Node 12, and that, that's helpful. And one of the big problems that we're trying to work on is how to promise event emitters. So promises are settled only once and event emitters give multiple responses. And HTTP and NET both use event emitter, so that is kind of a big problem. The good news is events.once is done. You know, that, that only, you only get one response from that, so you're good. You can make that promiseable. And events.on needs an async iterator, which as James points out here, it's now possible to consume NodeJS event emitter events using async iterators. Now if you saw Miles, not Miles, Mateo's talk yesterday, there are still some problems with that that we're working on, but it is possible if you take the right steps. I think, I don't know if it was James or not, but somebody was warning me about having these conversations and getting stuck down the rabbit hole of micropreformance, so I'm going to skip this slide. I guess the point is don't obsess about micropreformance if you're looking to solve a larger problem. So, good news everyone. Things are getting better, right? Some APIs are already done. As Miles pointed out earlier, there's been some other work that's been happening. Some PRs are already opened. There's progress. Things are happening. In fact, we met in Berlin at JS Compu, the last one. Unfortunately for now it's really the last one, and had the collaborator summit after the event. And we had a really great session on promises. There's a lot of folks there and a lot of people interested and a lot of people raising hands for things that we're trying to get done. And one of the discussions was default behavior for unhandled rejections in Node.js, which is a complicated topic that there was a survey going around trying to figure out what's the best way to approach that. We took some time to go through the core APIs and figure out what the status is for each of them. I think that this spreadsheet is online somewhere, and I need to go update it. But like I said, there's movement. So there is Matteo closed a PR not too long ago, and this is around Emitter. And the hope is that some work that's going on at TC39 will help with some of this. And again I think Matteo's talk was yesterday, so he talked a little bit about that if you get a chance to see the replay if you didn't see it yesterday. It's a good talk. And then again Matteo, who is the maintainer of Streams, so he's really focused on event Emitter and this work. He landed a change nine days ago, so it's actually not in a release yet, but he landed a way to capture rejections for async handlers. So this is really new, so I just thought I'd grab some context from the GitHub. Well I say this is really new, but he actually opened this PR as you can see in May. It had been around a while and there were lots of comments and updates and tweaks and stuff, but it landed about a week ago. So as he says here, one of the biggest sorts of issues with unhandled rejection is the use of event Emitter in combination with async functions. And currently there's no safe way to catch a rejection when it is emitted with an event handler, causing hard to track bugs and memory leaks. The basic practice right now is to wrap stuff in a try-catch and handle errors that way, but that's problematic for a number of reasons. So as he, in landing this there are some updates to the docs as well and as he says here, using async functions with event handlers is problematic because it can lead to unhandled rejection in a case of a thrown exception. So this is similar to what we're looking at before where things get swallowed up and you have no idea what had happened. So this PR adds a flag to capture rejections, an option for event Emitter constructor, and you can also set a global setting for a file to set it as well. And then in doing that, under the hood when the promise is created, a dot then is added to it to be able to handle rejections and surface them. So that is good news, right? So like I said, there's movements. I wanted to use this talk as a little bit of a call to action. Obviously, if you're sitting here at 9 a.m., then you're interested in promises in Nodecore. So I want to point out that it is a strategic initiative at the TSC. It is actually a two-year-old strategic initiative, but like I said, there's been progress. This is not an easy problem to solve in some of the areas where it would be most useful, like HTTP and DNS. And like I said, we're trying to manage the effort. And so there are lots of places where people can get involved and start helping with it. In fact, I have a PR that I've been threatening to submit for a while now to promise-ify the crypto APIs. Unfortunately, I bought a house right around JSConf EU. And will this actually play? I don't know. Yeah, well, that's a bear in our yard. And I haven't sold the old house yet, so I'm like crazy busy. But I have a New Year's resolution to get back onto promises. So in January, I'm going to be back on the case. We also have Collaborator Summits starting tomorrow. So if anybody is going to still be around, please come and hang out. We're going to talk about promises in a number of contexts. On Friday we have stream support for promises and a discussion on streams on Saturday as well, which promises will be a part of, I'm sure. I also want to call out, I actually think I have a slide later on, but it makes sense here. James Snell has a talk after me, so stick around. And that's about using promises and some tooling to help you with using those and surfacing challenges with promises. But generally speaking, come and talk with us. If you're interested, we'd be happy to have you helping out on this problem. Because with your help, I can promise you we will resolve this. That was just one pun at the end. So yeah, thanks.