node

This sort of work is something I wouldn't be able to do, but I can't help but point out at least one potential issue with the paper. It's a lot easier to find problems than solutions I guess. Are the benchmarks comparing node versions valid to conclude a real world performance increase? one possible confounder is the version of V8. https://github.com/nodejs/node/blob/v18.x/deps/v8/include/v8... https://github.com/nodejs/node/blob/v20.x/deps/v8/include/v8... ideally, they would've patched Node 18.15 with their changes directly and test their patch against 18.15.

Vitest does not support CommonJS mocking as of today. I switched to Vitest because Jest was giving me flaky coverage results: https://github.com/nodejs/node/issues/51251 And while Vitest' coverage is stable, I had to add an indirection layer to change how I mock out calls to GitHub's API (@github/octokit). Oh, side note: vite-node's --watch functionality does not restart the process. It does hot reloading which is different enough that it requires some rework at how you set up your app structure and callbacks.

> This isn't actually about removing the promise (completion) listener, but the fact that promises are not cancelable in JS. You've made an interesting point about promise cancellation but it's ultimately orthogonal to the Github issue I was responding to. The case in question was one in which a memory leak was triggered specifically by racing a long lived promise with another promise — not simply the existence of the promise — but specifically racing that promise against another promise with a shorter lifetime. You shouldn't have to cancel that long lived promise in order to resolve the memory leak. The user who created the issue was creating a promise that resolved whenever the SIGINT signal was received. Why should you have to cancel this promise early in order to tame the memory usage (and only while racing it against another promise)

This doesn't even really appear to be a flaw in the Promise.race implementation [1], but rather a natural result of the fact that native promises don't have any notion of manual unsubscription. Every time you call the then method on a promise and pass in a callback, the JS engine appends the callback to the list of "reactions" [2]. This isn't too dissimilar to registering a ton of event listeners and never calling `removeEventListener`. Unfortunately, unlike events, promises don't have any manual unsubscription primitive (e.g. a hypothetical `removePromiseListener`), and instead rely on automatic unsubscription when the underlying promise resolves or rejects. You can of course polyfill this missing behavior if you're in the habit of consistently waiting on infinitely non-settling promises, but I would definitely like to see TC39 standardi

> Promise.race Ding! You now have a memory leak! Collect your $200 and advance two steps. Promise.race will waste memory until _all_ of its promises are resolved. So if a promise never gets resolved, it will stick around forever. It's braindead, but it's the spec: https://github.com/nodejs/node/issues/17469

> Use the standard library (ironically not available for Node projects) ??? Node.js has an extensive stdlib [1]. Contrast that with Python which practically requires a 3rd party HTTP client. Or Java that doesn't even have JSON support. [1] https://github.com/nodejs/node/tree/main/lib

Uh, you are wrong. It absolutely is a thing and it has been in your browser and Node for longer than a year. https://github.com/nodejs/node/pull/48518 https://github.com/tc39/proposal-explicit-resource-managemen...

If you are bored you can read the discussion when _mnot_ tried removing 418 status code from different languages and implementations because it wasn't technically correct. https://github.com/nodejs/node/issues/14644 https://github.com/golang/go/issues/21326 And someone even ended up making a website http://save418.com/

A coding world with more standardization will be better world. I met this week "Standardized Interface for SQL Database Drivers" https://github.com/halvardssm/stdext/pull/6 by example then https://github.com/WICG/proposals/issues too. Huge work to get everybody on the same page (About my previous example, it's not well engaged by example https://github.com/nodejs/node/issues/55419), but when done and right done, it's a huge win for developers. PHP PSR, RFC & co are the way.

The node versioning system makes no sense to me. They release a new major version and their key highlights sound like minor version changes: > Enabling require(esm) by default for Node.js applications > Removing support for Windows 32-bit systems > Stabilizing the node --run command > Enhancements to the test runner, including glob pattern support for coverage files When Java or especially C# increment major versions, they've added some key language or compiler features, large new standard library changes, or breaking changes of some kind. Node uses major versions to announce what more or less sound like housekeeping. Unless they're just bad at writing blog posts, which it seems like they are. Under "Other notable changes", they have: > [83eb4f2855] - (SEMVER-MINOR) deps: V8: cherry-pick cd10ad7cdbe5 (Joyee Cheung) #52535 Which tells me l

JS concurrency is crap. It should be shot and buried in a lead coffin. Debugging async code is pure hell. With Go, you have a normal debugger that can be used to step over the code. You can get normal stack traces for all threads if needed. There is a race detector that can catch most of unsynchronized object access. With JS? You're on your fucking own. You can't find out the overall state of the system ("the list of all threads"), without getting deep into the guts of React or whatever framework you're using. Debugger is useless, as each `await` call drops you into the event loop. So pretty much every complicated non-trivial JS app ends up with _tons_ of race conditions, by depending on the order of async functions finishing. Speaking of race conditions. Coming from classic multithreading and Go, I tried to use `Promise.race` to simulate

At least Node.js has added experimental support that seems to do that: https://github.com/nodejs/node/pull/53725 But this is just an on-the-fly transpile(natively supported). It would be much better if JavaScript would go the Python route. For that they would have to extend the EcmaScript spec (to be safe) I guess. Just using JSDoc is imho not a good alternative. The big benefit of TypeScript is that your compiler checks this all for you. I've seen to much incomplete or wrong JSDoc in my life.. also a nightmare to maintain.