 That's really cool. Thank you very much. So yeah, the internet is also soon going to listen in. And just to give you an outline of the other topics that we want to discuss today. So relatively recently, I landed the PR to opt into a specific behavior for unhandled rejections in the core. No, no. Come on. There's more like years of work. Years. Okay. You have three different modes that you can choose of. Which means like all warnings are gone. Everything works as in the browser pretty much. And then you have warning, which is pretty much the same as the default. And right now that you will get a warning in case of unhandled rejection, but you do not get a duplication warning. And then there's the strict mode, which results in throwing an error instead of rejecting something in case of an unhandled rejection, which should normally cause the process to crash in case you don't have an uncaught exception. Now, the thing is, we last time on the last summit, we discussed that we would only want to implement that. And later on decide on what should be the default in Node 4. So now we are at the state to discuss what should be the default. And for that, I don't think it's actually our duty to really do that. And instead let our users decide on that. And that's why I would like to do a survey. And we are going to have the opportunity to gather some questions from you about it and to provide the necessary information to actually then do this survey. It should of course be unbiased, try to explain a couple of things, have examples, and so on. Then we have our multiple resource hook, which is great, but it doesn't work as we had hoped for. The problem is that I promise who's familiar with unhandled rejection. So all right, that's pretty much everyone, that's good. So the problem there is if you have .race or .all, it would also end up in there. And that's not cool because especially with race, you do not care if it resolves more than once. And it uses the underlying problems constructor, which then ends up in the multiple resource. And we do not have the information to change that right now. So this is an ongoing discussion with the VA team a little bit. And there are pretty much three solutions to either have extra type that could be implemented to know where the multiple resource is coming from. It's a tricky part. It's not easy to determine. Or it is just not logging it for and promise all, promise all settled and promise race and all the built in function that potentially come up. And as the last point, we discussed that to lock unresolved promises on exit because it normally means like we get often issues on the Node.js issue tracker that, hey, I run my code and now I actually thought the promise would keep in my process alive, but that cost was exited. What it means is that there was no IO or anything going on anymore in the application and the event loop just ended. So it means the promise actually never resolved because otherwise there would probably be some work afterwards. And therefore we can warn the user about it and tell these promises at these lines never resolved. You should have a look. Yeah. So that's the overview. If you want to continue. So promise APIs are both, I think, very complicated, but also somewhat on rails. Mostly in the sense that we're going through, we have APIs that are already defined. So for the most part, we're not going through it by checking on what new APIs should be. At least the pattern that we've done right now is we're not recreating all the APIs from first principles and rethinking them. We're taking something that already had a callback interface and giving it a promise interface and generally trying to do something that's a little bit better than the status quo. So like if you think about what we have in the past, and I think a good example would be like what happened with FS is like at first off there were no promise implementations at all. Then you tell promise by, thank you, and I think that was you, right? You still promise by is a really great utility. And then just try them in when I get this wrong. If I do, it allows you to take a callback based API node and turn it into a promise returning API, but it uses underlying the mechanisms to create that promise. So no, it used to do this. And I think at some point that made it use the utility supply. It used to do the native. Thank you for correcting me. So does it not have the performance benefits anymore? So actually, in doing that on the C++ layer, prevented the VA team from optimizing the promise constructor more in this case, because the C++ layer couldn't be optimized. And having regular code could be optimized for it. At least that's what Benedict told me at some point. And the young might who's not looking or listening. Yeah, it should be pretty fast. And when I did the performance comparison, it was, I think on par. Cool. So that evolved. But then like going, yes, random question on what you just said about performance. I'm curious if you're benchmarking on different, like, hardware, like devices like arm versus, like, you know, like, I'm curious, like, if those benchmarks come into play, like, like the device device matrix comes into play with your benchmarking. Very good. Yeah. So we have a CI system where we can pretty much test any system that we test on. But I believe it's only configured for a single system. I'm not sure. And I run my benchmarks locally. I don't see you. And so we do not do cross platform benchmarks, which is mostly not a huge issue as far as I can. That's like, when we did the benchmarks, the VXA's benchmarks on eventually, oh, sorry, it's a recorded thing. Sorry. So when the V8 benchmarks for promises are based on the bluebird, the bluebird benchmark for promises. And we have never rounded on anything other than our laptops. And as far as I know, they don't, like, V8 doesn't run their benchmarks on different pictures for promises. Maybe. I think we mostly run it on like 64. So in general, we also test all of our devices. I'm not sure whether we also do it for this particular promise. So I'm gonna, that's fine. We're running it back in. You told promise five was like our first major push to try to add promise for as many as possible. James did work on FS promises. That was, you know, a more direct implementation that's specific to those FS APIs that expose promise based APIs for, I believe, just asynchronous interfaces. Correct. So I believe that was the first one. And then yeah, we DNS also has been done. I think there's a, I won't call it abandoned, but an unloved pull request from me for trial process. I think in general, though, it can be non-trivial. You're touching a non-trivial amount of code to do these refactors and to make these new APIs. But the API surface is defined. There's examples of other APIs that have already been done. And if we at least as a group agree that this is something we want done, I think this can be a good way of leveling up new contributors by identifying the APIs they can work on. In terms of the API surface area, a lot of folks have made suggestions that, you know, we take an existing function that accepts a callback and if the callback's not passed, then just return a promise. We cannot do that consistently. You know, some of those functions already have return values. If we change the return value, then it's basically a December major break and change. The way that we've been doing this is to make it the introduction of a new, of a promise type version to be sent for minor. So we're not breaking any of these encoder or any assumptions on existing API surface. That's why we have FS.promise, right, or DNS.promise as a separate set of functions here. And then the second point, the reason FS has done the way it was, is so that we could avoid a duplicating code. Most of that, of the async activity within FS, it actually happens down at the native layer, not in the JavaScript layer. So what we do is we create a promise on the JavaScript side, but we resolve it on the C++ site there without duplicating the code to also do the callback version. So on the JS side, there's, you know, it's a separate set of functions that are defined there, but under the covers, the native layer is the same code in either case. DNS has done it in a slightly different way. So in each one of these transitions, we actually have to look at the specific way that the module and those eight guys were implemented. And, you know, there's not going to be a single pattern that's going to apply to every module. Sorry, just to like understand, like, since that's my learning, so I, to be clear, like, the different, like the reason why you have that difference where in the JavaScript layer where you have multiple implementations, but at the native layer, they all utilize the same path is to kind of, like, to preserve the breaking, like, to preserve the API. For... Preserve the API, eliminate the application of code. We do preserve the existing API, eliminate the application of code, right? And, you know, the less we can duplicate that code, the fewer chance of bugs and differences of behavior. It also offers, like, a good opportunity to, like, abstract out and figure out, like, hey, what within this module is, like, the core functionality versus what is more of the interface. And at least for FS, I think, when I was reviewing that code, a lot of kind of what was the core or, like, underline plumbing of FS is kind of broken out and then what's really different is just the interface into that plumbing. But I guess at a high level, what I think, and maybe we need to identify people and pair them with the APIs, I think that these are really interesting opportunities to give bounded work that's more advanced than, like, changing a line in a test, which is how we traditionally, like, doing our onboarding through code learns. I would love to see if, A, we can make more of a concerted effort for moving these promise APIs forward, but also, B, if we could use this as a way to level up newer contributors, create new code owners for parts of our code base, have people be more familiar with parts of our code base. But it will require, you know, like, some mentorship and some oversight and some support. And I also think just in general, like, I know for myself, when I opened up the child process one, there was, like, a handful of pushback about, like, how I should do it and some light shedding. And honestly, I just didn't have the energy to finish it. I'm quite familiar with course, so I can imagine someone who is not me also not getting it done. But I just think if we really wanted to tackle this, like, perhaps we need a working group, or perhaps we need a team, or perhaps we need more of a concerted effort, but we should be, like, fairly consistent in the way that we approach it and review these things. And have, at the very least, maybe some resources and documenting, like, what do we need to make a promised API so that we aren't, like, re-litigating what our expectations are every single time one of these APIs comes in. We should be consistent and all the APIs should be held to the same kind of, like, bar of expectation and consistency. So I think for child process, for example, one of the things that was blocked is, like, what are you going to do with all the sync API? Should all the sync APIs also be exposed in the same interface? And I just didn't have time to, like, go through and litigate all that stuff. But we should just have, like, maybe a how-to guide. You're, so you want to promise a fine API. Here are what the expectations are. And if we have a review and it's not in that guide, like, it should get added to that guide or it shouldn't be necessary. It's going to take, it's not going to be complete, right? It could take a first pass based on what we've already done. But that guide itself is going to take a few, take some iterations because there are still some parts of the existing API that we're not quite sure how we've done. And like I said, it's not something that currently we have a clear set of rules that will apply consistently for us. We have to figure out what those are in part. Yeah. So I think based on that, we can think of this as like a living document that we iterate on, but at least becomes the source of truth for kind of the history of creating these APIs and what the expectations are. I would volunteer to help work on that. Is there anyone else who would help with creating this document? James, I don't know. I thought it was like assuming Coleman and James. He just, he promised to do it, but it resolved late. Just wanted to make sure you didn't reject. Cool. Ruben. Yeah. So I'm not sure how much more we should look into this. There's still a couple of questions around implementing native promise support in the different APIs because our APIs partially look very different. And like, for example, events have very different requirements than like FS. Then we have promise support and assert, which have a different name to the similar functionality like assert throws and assert rejects, but that's different, for example, with FS because we have read file and we have promises.read file, which is the same name for the function. So it's not completely clear always, but only looking at the function name, what it is about, if it uses a callback or not. And these things have to be decided while implementing the promise based APIs for all the modules that we did not look at so far. So one of the challenges on, there are two challenges on some of those, especially on HTTP and net. And those are related to how we receive, show new connections. And because if you're using HTTP server or a net, or you're building a protocol on the server or the net or TLS, you are essentially using an event meter. So we emit a new connection as a new event. And the hard challenge there is we need to decide which type of API do we want to provide in a promised way. Like what does it mean to promissify, to support promises in a world where we are emitting an event. If you're creating an HTTP server and you're doing HTTP.create server and you're passing an handler, which takes a request and response, that in fact gets added as an event listener to the request event. Now it means that the core functionality of our HTTP server, which is the important part of the node, relies on an event meter. Now what does it mean to provide us a promised API for that? And this is one of the questions that we still have not answered. There is certain type of discussions and certain type of APIs that are being circulated from, there is de-noise implemented something on that area. I personally don't like what I've done. I don't think that's a great idea, but that's my personal take. Yes. Okay. So yeah, yeah, no, what I was saying is it's putting down, going down to that path in order to provide the, and that's the first one. So we have our servers are having to meter. So in order to provide an API promise version for those, we need to figure out what is the pattern for those. Okay. And the second one is what do we do with streams? Again, request and response, we know it's from streams. So what are we, what does it mean for having a promise version for these? And in order to do crypto, TLS and HTTP and net, we need to solve those two problems first to some extent, rather than, because if we don't, then we can, we can't promise if I don't listen. Okay. But, you know, that's not, it's an API that gets called one proposal. Yes. So it's not really, you know, we're not re-providing a better user experience. We're not improving on the day-to-day. Okay. So, you know, that's, I just wanted to say there is a kind of a blocker for this, if we need to figure out what those means. And if you're interested, if you figure those out, let's chat a little bit, because I'm available. I've done an API, but that's, if we have some time at the end, I will just show my PR front. The question is more like around your, your, your problem of managing, like, you know, all, all of these different events that have different kind of APIs. So, I'm just curious if, like, this is my, like, web application developer brain, right? But, like, the way I could solve this problem is, like, having a, like a, like a, like an event manager, like, essentially for my events. And so that, and like all of the details of, like, you know, you're using queues and stacks and, like, it's the comp, you know, and you're, and there's all the implementation details are inside that class for knowing how to deal with, you know, the different types of kind of handshakes, you know. So, I just was curious if something like that would be an option. So, I would prefer not to re-implement anything from scratch. That would be my, that's my answer. So, what we, what I think we need to provide is something that is very similar to what Node does right now, but with an additional functionality. Like, having to be done on streams are part of our inheritance chain for a lot of things. So, essentially, in order to replace those, so we cannot, so the challenge between these and FS.promises, for example, is that, as James said, FS.promises is a full new implementation, okay. With event meter, event meter is as part of, as in our hierarchy. So, HTTP server is added from event meter. So, we probably cannot follow the same approach, or we need to think if we want to do to follow a different approach. But that would mean, it might need to, you know, implement a significant, significant chunk of Node internals. All right. Thanks a lot for all these good insights. And I guess we, so here in the issue, there you will also find a link. I just opened a new issue in the summit repository for the session. And you will find a link. There's a link for all the modules, in case you want to go in there and make a comment or so, and to also find and document again. I would like to continue now with the rejection survey, because I don't know how many of you would be comfortable of deciding what should be the default in Node Core. Like, would anyone say, like, yeah, they have a strong opinion on what it should look like? A couple of hands, like, all right. Like, what, and these people who have a strong opinion, what do you think it should look like, if I may ask? Well, I don't know. Who wants to go first? For debugging purposes, the strict moment would be beneficial, like, having a default that shows information rather than losing it. It's getting brief. So like, the one thing that I definitely do care about is that I would want the process to exit with a non-zero exit code. Like, branch, or the winding or whatever, but like, that should be there. I want consistency with errors that are not encapsulated in the process. I think you actually have to take the non-engineering approach to this. These are all nice things to want, but really, you've got to look at what Node is. You have a lot of customers that use it. You should actually just speak about the reputation laws and what's best for engineering this one feature. Strict may not be the best. Can you elaborate? I'm more sure it was able to come. Okay, so if we have an option, a strict option, unless it's used wisely by users, and you can't use trust users to use this wisely, you could damage your reputation. People might see it come along unnecessarily, and that's something you don't want. Okay, I'll take every step and not to alarm anybody. Even the talk of the word exiting, I will throw a lot of people into panpony. Do you know how it is implemented right now? Do you know how the implementation looks like? Because it does not exist in strict mode. So just to give you an outline of how the rules exactly work like, so none just surprises any warnings that are currently locked. At the moment, when you're running into an unheld rejection using Node.js, it would lock multiple things. First of all, it would lock a warning and that you have an unheld rejection. The second, it would like for the very first one that is locked, it would also tell you this is deprecated and please handle all your rejections. And I believe there isn't even a certain thing, I don't have it in my hand right now, that gives you an additional context a little bit. How, like where the error originated from. So this is the current warning thing, and if you opt into the warning mode, it would still do the regular warning and give you the context where it came from without deprecation warning at the beginning. And the strict mode would not exit with a non-zero exit code ready fault. What it does instead is when you're running into an unheld rejection, it would then turn that unheld rejection into an uncalled exception, which then has by default of Node.js the behavior of exiting the process with a non-zero exit code, because that's the process for uncalled exceptions in general. That's just the case. And so you could still stop that by having an uncalled exception hook, which would mean the process could continue log stuff or whatever the user would wish to have the default. So that's how it works. And I hope that clears that. Okay, great. So thank you very much for the feedback. All right. I miss someone. So I pretty much agree with everyone that we should do the same thing we do for regular errors. And I would prefer to do the same thing on uncalled exceptions and on uncalled exceptions in async functions. And I just want to echo that it's something that the URL of complaints about. So I think there is a lot of new developers coming to Node, people that don't know how JavaScript works and don't know how promises work. And there are just lots of non-shipping business features. And they're not maybe not even interested in learning more about the internals of the language and internals of the runtime. And I think whichever default we choose needs to take into consideration the fact that we should try to make the most sensible things to avoid them huge problems in production, which is, you know, great. Yes. I would have finished. So essentially make things as safe in production as possible by default. And the reason is, again, there's a lot of, you know, mixed, mixed problems in the wild on async functions and promises and I mean, the meters and pullbacks. So, yeah. And yeah, I would say that it's safe for people. And I personally think that that is, you know, exiting. But that's my current, that's my take. But there are other things that we can do to mitigate those problems and avoid those problems. So we might even, you know, do something slightly different. So essentially there are other options. Okay. So I hope it's like, from hearing all these different opinions, I hope it's fair to give like an outline of what my feeling is and that this room would mainly wish as a default. And that sounds like it would be the strict mode probably. Does someone strongly disagree with that? I don't see any hands. Cool. I think that's actually a pretty nice outcome just too far our, as a recommendation in the outline. There's a lot of people that are not here. Yeah, yeah, definitely. There are a lot of people that are not here. And I don't want to decide anything in here. Just to make it clear. Matilda, there's nothing to decide here to do. All right. So what I do want to, or I wish at least, is I asked every single one of you to open up this issue and to go to the document that is linked there, linked to the survey questions. Because what I actually think is best to do is to make a survey and to work on that very well. Like when we gathered enough question that should hopefully like please try to be very unbiased, outline frozen cons for different things, give examples. All these things could be gathered in the document. And then I'm going to go to the diagnostic working group who is that again, where it's raising over it, making the final questions, giving that to the survey working group, which we do have as well, and then to send out that as a survey. And if that results in a clear opinion, I think it's significantly easier to follow up on whatever our users think is best or not. Even though we personally already have an opinion in what direction it should hopefully go. Right. Is there anything else on this topic? Otherwise, I would continue. Does anyone want to add something? No. Good. Does anyone disagree with that, like with my suggestion? No. Okay. Well, I hope you think it's a good idea. And let's go to the multiple results hook. So this is a bit tricky because at the moment, it is not really a good use case because of the false positives in a way. Yang, that's a personal question to Google. Do you think you could work on that to improve the output so we can actually tell our users more about it? We can definitely have to pick some patches. It's probably not going to be too hard. So if we have some free cycles, I'm not sure we have planning coming up. So maybe we can Okay, cool. Anyone want to add something to the topic? Because I guess there's like, we are pretty much blocked on Google or anyone opening a PR on that. So it's like everyone who knows C++ well and wants to work a little bit on V8. To be fair, multiple results is a hook V8 added for us after we asked for it in the last call-up summit. And we didn't specify for enough. And this is my fault. And we didn't think about all those edge cases. And I think the big challenge in multiple results right now isn't the C++ side. I probably won't go through the V8 process, but I don't mind writing the code and have someone from V8 go through the process. I think it's mostly blocked on deciding what we want from the hook and specifying the edge cases. So someone can write tests, failing tests for what multiple results should do in all these cases. That's what we're stuck on right now. Yeah, I think that's a cool idea. Would anyone be up for that? No? All right, let's hope we can move forward with their topic soon. Because I personally believe we should try to have the best debugging experience for our users when it comes to promises that's possible. And that would be part of it. And because they might run into issues that they're not aware of, because the promise constructor is pretty much tensile, you don't know what happens there if the promise is already settled. Because it cannot change the state afterwards anymore, even though it might result again or reject afterwards, something like that. Actually, after talking about this, you do know about the problem itself, or who does not understand the problem with multiple results. So at the moment, the promise constructor, when there's a synchronous error in the promise constructor, it would be rejected. And that's good. And if you call either the reject or the resolve function, it would be settled. Like as soon as you have it rejected or resolved, it's called settled. And then it is in a new state, and it cannot change that state afterwards anymore. It will always stay rejected or resolved. But the problem with that is that the promise constructor does not prevent any further code to be executed in the constructor, even though it is already settled. Now, if there is a second error or a second resolve, something like that, in there, it will still be executed. And it could cause side effects and errors that you don't understand in the output, because you don't see that. Because it's just silent pretty much. It's a dead zone from the code. I'm a little bit confused. So promises are immutable, like that's like the best part about them, right? Like once they're resolved or rejected, that's it. So why is this an issue? Like code after the return statement? No, no, no, it's not about the return statement. Yeah, sorry. So Benjamin is going to show a nice example. It's only about the constructor, the promise constructor, a new promise. And then you have the function that receives up to two arguments, which is the resolve and the reject function, that you can then call in the promise constructor to settle it. But you can call this function or both functions multiple times, which would cause the promise not to change the state the second time you call it. And it would also not take any value, even like let's say you resolve twice with different values, it would only take the first value that it received, and it would not know anything about the second resolve anymore. So if we resolve with some value, and then we call some function or do some cleanup, and it's a very nasty bug. I've seen some big code-based companies. Then this second, like the promise constructor is built using this pattern called the revealing constructor where it takes the function and executes it synchronously, and it converts thrown exceptions to rejections. That second line, that some function call, if that throws, that exception gets swallowed and like no one knows about it. And the multiple results gives you a hook that gives you access to that second exception. And the bug I've seen is where that function call was clean up this resource. They had a typo in production. Clean up this resource didn't execute, they did, and like no one saw theirs. So this is why it's something that we want to do with this. So practical example of this, just for the reason why another one was, I don't wait in the episode, if you have to open the promise constructor, you have to manually close it, right? In a cleanup logic, the promise constructor was not being closed, and so we're really getting promise developers, specifically because of this. It's interesting to note that there was just recently on Twitter, supposed to be debating with me about whether multiple results should be allowed, and the argument was that we shouldn't do anything here, just let it resolve multiple times. And the argument literally was that resource weeks can't happen with promises. There's this perception out there with people that are using this. If you use the guide in a certain way, that stuff cannot happen. But practically speaking, in real world, these things are happening. And specifically, even though, because of things like the policy record. Yeah, thank you very much for talking to us as well. I hope that answers any questions. Yeah, thank you very much, the visuals, we're really helpful too. So, this is a problem that only occurs in the promise constructor? Yes. Because that makes it actually easy to filter. Yeah, but no. So, the problem is that promise.all and promise.raise and promise.all tackled, I'm not 100% sure about all tackled because it's still very new, but it is, as far as I know, it uses the promise constructor all and because of that, we are receiving multiple resolves with notifications from promise.raise, which is super bad because it's actually meant to resolve more than once. And that is something like this. It does like promise.all ready, but for each note, it's going to be very, I don't know what it is. Yeah, but I'm not mistaken, at least in the VAT implementation, promise.all is different, so I think we should be able to take the risk, right? Right, yeah, but I think from the way it is implemented, it seems like it could be hard to implement that in a reliable way. Maybe you can implement it to work sometimes, but because it's so dynamic with calling the event method, like if you patched in to be a function which like does something else and then calls the original event, you might not notice that it was originally done. So anyway, at a higher level, exposing more debug information to people sounds great, and I don't think we're going to change these things in the JavaScript standard. There's a lot of things about promises that I personally find very regrettable, and I think you identified other things that I wouldn't have thought of as like, you know, there's many dimensions of interesting design choices here, and at the same time, they're shipped very widely, they're very widely used, and I don't think the standards are going to change. So to the extent that note is, you know, clarifying these things, I hope it can be really restricted towards making like a subset of behavior and like making warnings or maybe crashing everybody or something like that, and not going and adopting different semantics, even as tempting as it can be. So this is something that Ruben Madd talks about offline, where he said, like, isn't this case bad? Like, yes. And, and I don't think we should change it because there's so much use of promises, it's just not, not the time to change it. Going forward, with TC39, I want to be more open in consulting. I mean, I know that promises were designed in such a good way, and then there was this sort of something happened that they became a standard and they always were things. So just for some historical context, like the promise constructor that is behavior, we just think it's a good idea. So it's not like we didn't think about this case that what we had in nine is if you're referring to the API to promises, then you have to handle both synchronous and asynchronous errors. And the way the promise constructor works is that it normalizes that if you only get asynchronous errors. And like the thing about multiple results used to think it's a feature because we didn't have to consider this case. So it's not like the fact that you can resolve multiple times and it will only look the first one is intentional. And that actually takes back to some of the e-language stuff. And it's not like it's positive. The fact that it's flat scripters, because you can put an error after you, it's not intentional. Because this is not the API you started with, the original API was deferred. We did a promise not deferred, that's the first API that's chrome shipped. And this API was supposed to be safer. And I think that if we would have known that, we would not have achieved this. Well, yeah, I was involved in unkipping promise type for what it's worth. So anyway, stuff happened. There were rationales, lots of rationales about every single little case. And we ended up where we are. And at this point, I hope that note can remain compatible with the broader ecosystem and with a variation, just maybe create errors and help developers with that, but not change anything. We are not there. There is no point where we want to change semantics specifically for Node.js. It's only providing extra information errors. I'm super into ASTs. And actually just talked to Mitja and I were like, by chilling on something, and we're going to collaborate on a project where he's basically just going to give me his list of problems. And I'm going to use my AST knowledge to build a linting tools on AC guidance patterns. So I'm really excited about this. By the way, I'm going to file an issue in the summit so you guys can follow. But I'm curious if there's just a part, I think there's like a, like the advocacy piece for this could be creating a linting rules around do not do this. Because for me, there's a major separation of concerns that I've seen here. And the platform shouldn't have to write a bunch of code to stop developers from shooting themselves in the foot because the stack was bad. The real fix should be fixing the stack, but I guess for whatever reason, that's not possible. I'm not sure why, but I don't want to get into it. I'm just curious, wouldn't you guys think that would be useful to have linting plugins that we are outside of widely recommended linting rules for Node. Just to say, hey, community, like there's stuff you can do that's going to hurt you. And we really recommend you, just because you can do it doesn't mean you should. And yeah, so forth. So I mean, that's just a way to kind of programmatically, like pivot in the bottom. Just very briefly, we don't have a lot of time anymore. There's still a little bit and something else that I would also like to discuss though. And we like historically, I think, one year ago, we spoken about this, actually, there is a linter that does like a promised lint validation. There's an islint plugin and that works. It's not able to catch all the cases like an improvement we have warnings for stuff that's not analysable statically, like you get a parameter name, you don't know the type, that might be a promise. And then, or for example, one of the biggest issues people have is that they create promises in them and theirs, they don't return them. And then it doesn't wait for the then. I feel like 80% or 85% of these cases can be caught statically. And then there's like 15 that can't. But the problem is that the 15 are the hardest bugs to deal with. And actually know some good people that would love to collaborate with you on, like, I don't have to, but there's people who are better at tasting stuff than me that's about the problem. This about documentation, it really all seems really great. And we should simultaneously acknowledge that it's going to be, if we who work in this direction is going to be immediately not have the consensus with the whole world. Ultimately, these things are all political in some way, whether you're documenting how the world works or how the world should work. And we should be comfortable entering into that space. Absolutely. Okay, thank you very much. I think that's a great idea. I'm looking forward to using those rules. Then, so long and we saw promises on exit. And so the problem there is, as I said before, on the Node.js issue tracker, people relatively frequently come in and have say like, Hey, my program ended, but my promise never resolved. And my program should not end before my promise resolved. Well, it normally only resolves if there is nothing else going on in the program anymore. Because then the event loop is empty and Node.js cannot detect anything anymore. A promise is nothing that keeps the event loop alive. So as soon as it would resolve, and then there would be some work again for Node.js and the process would be kept alive. But obviously, the promise never resolved, so there's a bug in the program. And because in the branch, which should normally result in the promise to resolve was not reached. And this is confusing for our users. And it would be great to actually notify everyone about it. So I've spoken to Yang, we are on exit, able to iterate over the heap, which means we are able to detect what the objects are there. It's still alive. And then we check, is it actually a promise? If it is a promise and it is unresolved, I'm sorry, unsettled, then we could actually tell the user where this promise is currently at in the code and say, Hey, this does not resolve. Please have a look at that. That seems like the bug. Is that something everyone agrees on to implement? I think for the very least, I think this is also like, why isn't my code running? Like, so it's frustrating to debug errors. It's even more frustrating, at least for me, to debug code where code doesn't run and they don't understand why. And unresolved, like unsettled promises can be really frustrating to debug for some users. I think for the very least, we should expose this somehow, even if we don't want to log this by default, because there are cases where you'll have programs ending with unsettled promises, we should at least have some way to monitor this or device. So my suggestion about it is to implement it similar to the current unhandled rejections flag to have it there. And then we can again, at another time, discuss if we want to have this as a default. This is the exact thing you just put up there. Being able to enable it optionally does. I think it needs to be often, specifically, for command-like flag, where you can say, you know, I want a lot of complicated things. There's just going to be too many cases where worlds will want to be executed in the edge. So this, my original proposal for doing various different things with promises on exit also included this. And I mean, I feel that they could probably be added to the selection of unhandled rejection default warnings already, like default options. Like in the default case, we can go along with how the other setting is set for the unhandled rejection event. And so the default case right now would be to warn, which they would get anyways, otherwise, probably wouldn't be that disruptive. And then you could, if we changed that in some version, well, it could change along with that. Okay, so that's, so you're saying actually you would want to have it aligned with the current unhandled rejections flag. So if that is used, and someone would opt into either or a strict mode, you would want to log those as well. Did I summarize that correct? Yes. Although, thinking about it again, I might be thinking about it wrong because this was paired with a proposal that you choose to stop. But I would like the behavior to sort of be aligned with all of that. Okay, I guess we could have different barriers or different possibilities. I'm actually missing memory, but I think in your PR, the promises, like I'm sorry. So I think in your PR, it's a log the like promises that were rejected and not just ending, but they might be like missing memory. Because I think what you did is like, when the process exits, like log all the promises that are rejected and not. Oh, yeah, okay. Because I think there are use cases that like, especially in not so much in servers, but in the commanding tools, you have like hundreds of promises, sometimes in the code where the process exits, like people would just put process of exit in other places in CI tools. And we could actually also, and like, that's very valid point as well. So one question is, should we then warrant in case someone called process exit? What do you think? Yeah, I mean like process exit is just like a very explicit way to actually intentionally clear all the state that is existing in the process. And so I don't think that should trigger anything. Yeah, I think that's a good point. Right. I believe we are through. The time is also over. Thank you very much. And I guess we can continue with the next topic.