Hacker News Reader

Comment by bboygravity | Hacker News Reader

Does anyone know when we went from calling things serial and parallel execution to sync and async?

Was it before or after we started calling "man-hours" "story points"?

Async and parallel are a bit different.

Parallel means that things execute at the same time (or at least appear to do so). Async means that you yield control to some kind of scheduler and get it back at a later point.

Barring workers, JavaScript actually guarantees that two pieces of code never execute at the same time. That's the run-to-completion semantics.

When async was introduced to JavaScript from two different angles (callbacks in Node, Promise then await in browsers), there was limited parallelism involved (typically running I/O in the background), but the async was meant to ensure that:

1. while a task was (almost explicitly) waiting, another one could run;

2. in the case of the browser, we could yield control from JavaScript often enough that the UI could run smoothly.

Node didn’t introduce callbacks to JavaScript, they were present in the earliest browser APIs (img.onload, etc.)

Fair enough, I meant CPS-style programming.

These were just regular events on the UI thread, not any different from onclick etc., IINM.

So, the same thing as callbacks in Node.

When people talk about a callback in this kind of context they usually mean one function passed as an argument to another, in order to be invoked with the latter function's return value. Not event handlers like onclick, etc.

I’m not familiar with Node, but static event handlers aren’t usually referred to as callbacks in that context. “Callback” implies that something is being called, for it to call back to the client code. That’s not what’s happening with the onxxx event handlers. There is no “back” there. The event loop simply calls “forward” into the JavaScript code.

I don’t know what you mean by “forward” because there is no difference between these two:

  img.onload = function() {…}
  img.src = “some url”

  img.load(“some url”, function() {…})

The early JavaScript APIs use the first style, but the result is the same.

Async and parallel are not the same thing. You can run code async and yet not parallel (one core, no i/o).

Async in JS is not in parallel, which is a very -very- important distinction for program correctness.

JS, as typically run in a browser, is both async and single-threaded.

Parallel code runs parallel at the same time (on different CPU cores etc.)

Async code is scheduling different parts after each other. It's still running in a single thread (maybe on same core)

aaync essentially is non-blocking IO in many cases. It can also ahieldnsome logic running in a diffefent thread, hidden from that segment of code.

I think your explanation of async, while true, doesn't get at what's special about async. The explanation seems true of (non-parallel) concurrency as well (for example, thread scheduling on a one-core CPU).

Reply on news.ycombinator.com