promises-spec VS proposal-explicit-resource-management

Today, I tried implementing Promises/A+ from scratch to test my coding skill. In the process, I’ve crafted this guide to share my insights and experiences with those who share a similar interest. Without further ado, let’s dive in.

That made me chuckle.

For those not familiar with the promise design controversy:

http://brianmckenna.org/blog/category_theory_promisesaplus

https://github.com/promises-aplus/constructor-spec/issues/24

https://github.com/promises-aplus/promises-spec/issues/94

If you really want to go down the rabbit hole on this one, start here

Advantage 1, nesting, is the most important here, and it's often the most-overlooked advantage. Overlooking nesting is how Promises in Javascript got to be fundamentally broken.

Have you read the infamous GitHub thread where people tried to fix this before it got finalized? It's quite a trip

1.) JS implementation of Promise is not a monad. See this StackOverflow answer or this GitHub discussion for more details

In this article, we will go over how to implement a basic version of a promise during a FAANG interview. The standard for promise implementation is called A+, but it includes a huge amount of details, making it almost impossible to implement all of them during a one-hour coding interview. Therefore, we will focus on implementing a basic variation that should be enough to show the interviewer your solving skills.

Hey, at least you weren't these guys: https://github.com/promises-aplus/promises-spec/issues/94

Total carnage

The standard doesn't have anything to do with TypeScript, not sure where you got that from? https://github.com/tc39/proposal-explicit-resource-managemen...

The explicit resource management proposal tries to make it a bit easier for us, by allowing the resource to declare how it should be managed, rather than expecting us to clean everything up when we use the resource. We get a new keyword using to define a variable (rather than const or let), which tells the runtime to clean up the resource at the end of the function.

Enter the explicit resource management proposal, which describes — among many other things — a new using operator that was introduced in TypeScript 5.2 and is making its way into JavaScript. From the top of the README file, here’s what this proposal aims to do:

In addition to this, is the new (stage 3 even!)explicit resource management proposal[0], supported by TypeScript version >= 5.2[1]

Though I agree that async context is better fit for this generally, the RMP should be good for telemetry around objects that have defined lifetime semantics, which is a step in the right direction you can use today

[0]: https://github.com/tc39/proposal-explicit-resource-managemen...

[1]: https://www.totaltypescript.com/typescript-5-2-new-keyword-u...

It's too early for that, https://github.com/tc39/proposal-explicit-resource-management

[3]: https://github.com/tc39/proposal-explicit-resource-managemen...

I'm not _entirely_ sure which RAII you mean, but if you mean something like C#'s `using` or Java's `try-with-resources` or Python's `with`, then https://github.com/tc39/proposal-explicit-resource-managemen... and https://github.com/tc39/proposal-async-explicit-resource-man... are in stage 3 (of 4 stages) in ECMAScript's language proposal lifecycle and will be coming to a JS engine near you behind a flag soon-ish.