- Team_leader_1: I know you're a frontend developer, but trust me NodeJS has threads :) sync operations don't block the main thread :)
- Team_leader_2: You need to study the theory :) NodeJs can handle further operations during the sync function :) it spawns a new thread, you haven't studied Javascript well enough :)
- Me, very ready to dab on 2 condescending little fucks:

🤦

Please destroy them.

I don't give half a fuck about roadmaps and tasks to complete and me being a subordinate, gather all the "team leaders" you want, if you run your mouth I'll delay everything else and prove my point. I am not going to let it slide.

@CoreFusionX write code, prove your point, make sure there's no further bullshit, take the W.

Wait, wait, what? How could it not block the main thread if you explicitly state that it should wait for those operations to finish?

Like, what is even their reasoning? And this is literally the documentation.

@msdsk I DON'T KNOW I'M THE FUCKING VICTIM HERE

A case of shit floating upwards. Do they still code as team leaders or were they promoted out of breaking stuff?

Condescending people don't admit to being wrong. If they're above you in hierarchy they will just claim that your style is bad, they were talking about something else, words like sync or blocking mean something other than what Node uses them for, or at best that it's unimportant and your'e wasting time. Then they'll hold a grudge against you.

Node has (worker-)threads and many operations (fs, network) use real threads in libuv tho
But the part about non-blocking sync code is bs

@devRancid unless you use web workers -we don't- the whole "libraries spawning thread" thing is not something we, as developers, should rely on. It just sort of happens, but it's an implementation detail outside the scope of what we're supposed to work with.

@devRancid

libuv has threads. Node doesn't. Because its memory model is based on a single thread, which basically forces any implementation to adhere to strict ordering, which can't be achieved unless serialized. Even if a promise (or otherwise task) is run on another thread, any subsequent code still waits for it.

Also, webworkers aren't real threads, since they don't share memory space by design. They are closer to IPC than to threads really (just like python "multithreading")

@CoreFusionX

The docs explicitly say they are "threads" that execute javascript in parallel and can share memory with ArrayBuffer/SharedArrayBuffer

@CoreFusionX They used to have shared memory, it got removed because it can be used to create a high-resolution timer. I don't mind tbh, racing the beam is a shitty hack that should be either encapsulated or discarded, but I definitely think that we could've received a big pile of safe synchronization primitives as an alternative.

https://developer.mozilla.org/en-US...

And python's multithreading is very different due to the GIL. Effectively running sync code concurrently/serially instead of parallel

@devRancid

Exactly like in JS.

Sure, it has no GIL, but a similar mechanism as you can't otherwise enforce the memory model.

Node operates on an event loop with microtask and macrotask queues with a perfectly deterministic execution order. What thread each item is executed on is irrelevant (an implementation detail), what matters is what the memory model guarantees.

each worker thread has it's own v8 isolate (globals, event loop etc) to achieve true parallelism, not a similar mechanism as GIL
And its all running in 1 process so not just fancy IPC with multiple ones

@devRancid

I know that, but it's still not full fledged parallelism since you have to coerce everything into a sharedarraybuffer (which is not simple to do when you can't manipulate pointers).

Node tries hard to prevent people from shooting themselves in the foot (and nothing wrong with that), and I bet they didn't even want to open this Pandora's box.

My point is, workers are implemented with threads, but it's an implementation detail. Node can't guarantee its memory model on a true multithreading environment beyond saying "sharedarraybuffer == you are on your own". Sharedarraybuffer is not a first class citizen. You can't, say, placement new an object into a sharedarraybuffer, you can't sit memory guarantees, nor many other things you'd expect.

Clusters also work so much more similarly to forked childs than real multithreading...

To each their own, I guess, but if you find yourself needing actual multithreading in Js, you probably chose the wrong language.