Hacker News new | ask | show | jobs
by moglito 1229 days ago
But there is no concurrency in Javascript! So even after this exercise, the running function still has to finish before the next can start. This will only create actual concurrency when each of the actors are themselves doing pretty IO heavy things where they wait for external processes to finish. Otherwise, if you actually have compute heavy processes that should run in parallel you should use the node.js cluster package or worker threads, both of which come with IPC built in already.
4 comments

> But there is no concurrency in Javascript!

Javascript has concurrency (which async/await and promises are).

It doesn’t have parallelism at the language level (but see, e.g., the Web Workers API).

> But there is no concurrency in Javascript!

Yes and no.

At the “ECMAScript”-level, JavaScript has no built-in concurrency, but every serious JavaScript implementation enables proper concurrency via the async primitives and the internal scheduling.

Put simply, if you know how to write async code properly, your JavaScript code can achieve high concurrency!

No. All the JS code is still executing serially in the same event queue. This is a good thing, lean into the guarantees it provides.
Sorry, I think you’re misunderstanding.

Highly concurrent code need not execute in parallel. Concurrency enables parallelism; concurrency does NOT mandate parallelism.

On top of that, it actually is possible in JavaScript environments like Node.js to write code that can, in fact, run in parallel.

But those parallel executions are running their own event queues.
In an async function, the only guarantee you have is that code between two await points is not interruptible. As you have more and more async operations, this guarantee gets pretty weak (if you have more than one pending async task and the current task yields, which one will run next?) and you have to start employing the usual locking mechanisms to ensure correctness.
From experience, it is a strong enough guarantee to prevent many race conditions.
JavaScript does have concurrency! Try the following:

    Promise.all([new Promise(t => setTimeout(t, 3000)), new Promise(t => setTimeout(t, 3000))]).then(() => console.log('done'))
You'll notice it prints `done` after 3 seconds, not after 6.

It just happened to be executed one by one but the VM handles the switching for us.

What you're talking about is parallelism, which JavaScript indeed does lack and you'd use cluster or workers for that. That's when things happen at the same time, outsourced to different cores. This is what JavaScript cannot do (yet?).

Is that concurrency? The CPU is not switching between tasks; rather, it's scheduling 2 callbacks to fire after a 3000ms delay.

If you could perform 2 tasks (e.g. console.log(Array(1e8).fill(0).map((a, i) => i)), and have both run to completion without a significant delay between the two tasks, that'd be impressively concurrent.

Concurrency is not parallelism:

- Concurrency is making overlapping progress on two or more tasks.

- Parallelism is making simultaneous progress on two or more tasks.

Concurrent tasks can run in parallel, but they can also run not in parallel and still make overlapping progress by either cooperative or preemptive scheduling. You can imagine that in some larger tasks you have these 3 second sleeps, but all tasks are able to make overlapping progress without blocking the other ones -- that's concurrency!

There is a great talk by Rob Pike: Concurrency is not Parallelism - https://www.youtube.com/watch?v=oV9rvDllKEg&t=23s
Or use a language that supports multi threading in some sensible manner..
You’re asking for low-level features. JS is a high-level language.
High level languages can have parallelism constructs. E.g., Ruby, in which threads have limited parallelism (only when running lower-level code that releases the GVL) has Ractors, which run Ruby code in parallel.
I’m just saying if you want parallelism then don’t write things in JavaScript