Hacker News Reader

> In other languages like C, Ruby or Python there is the expectation that whatever happens on line 1 will finish before the code on line 2 starts running

actually, if you are into asynchronous programming (I am), I would claim the opposite. When writing an async program in C# you need to be acutely aware that in-between any two sequentially executed lines, entire threads of execution could have been invoked and completed. If you don't design for that, you WILL have race conditions.

Moving to nodejs 2 years ago, and something that I am still mindful of, is that you will NEVER have race conditions, as the entire user code will execute in a single thread, with interrupts only occurring between callbacks.

I like it because it's very easy to construct high performance professional apps in NodeJs (most devs are not multithreading experts) but sometimes I miss the idea of leveraging tons of cores. But that's why we scale horizontally (more 1 or 2 proc servers, less 32proc servers).

I agree. Asynchronous programming is orders of magnitude easier to grasp than concurrency. Especially in low lock scenarios. Interlocked.Increment(yourPost) :P

You can still have race conditions anywhere IO is concerned, just not at a thread level (because no threads).

This is correct. Race conditions are still the most common vulnerability in web applications.

Take a classic example: a one-time use coupon. Without some kind of locking, two simultaneous requests would be able to use the same coupon successfully. Roughly:

  0.0s - [1] Client 1: Apply coupon
  0.0s - [2] Client 2: Apply coupon
  0.1s - [1] Server to database: Is coupon marked as used?
  0.1s - [2] Server to database: Is coupon marked as used?
  0.2s - [1] Database to server: Nope! All good.
  0.2s - [2] Database to server: Nope! All good.*

* Since the question was asked for both requests at the same time, the answer was "Not used" in both cases.

  0.3s - [1] Server to database: Update coupon as used.
  0.3s - [2] Server to database: Update coupon as used.*

         * Coupon has been used twice :(

Node's async model is not going to help you here. You will need something more, such as a mutex.

Nope, your ACID database will ensure that two writes in the same time for the same record will not happen. You don't even need to ask database if coupon is used. You just try to use coupon, if already used return message to user.

Node give you freedom from Thread Hell. You enjoy similar performance without locks, threads, synchronisation. Race conditions happen but mostly with cache invalidation where you can have limited consistency guarantees.

Right; you need to put your lock in the database, encoded as an index.

The problem isn't "two writes at the same time", it's the server thinking everything's OK for two separate users.

If can model your database differently for this rudimentary example, then good for you – you're thinking about race conditions. Many web programmers do not think about them at all, and race conditions are usually not trivial to fix.

> Use ACID compliant Database or not

How is that specific to only NodeJs?

agree. the coupon problem would be best fixed with atomic database transactions.

in fact, an entirely synchronous, 1-user-at-a-time server wouldn't fix this, if there were two or more servers. and honestly, who would design any system that only supports 1 concurrent user?

Calling race conditions the "most common" vulnerability seems like some pretty extreme hyperbole. What about SQL injection or XSS?

You're right, I meant to say the most commonly unaware vulnerability.

This is a problem in the database layer, not NodeJS!

While it's not "true multithreading", there are a lot of options for using multiple cores in JS now.

In the browser, there are web workers. When combined with the "transferrable" argument in the postMessage function [0] you can get zero-copy transfers (with the caveat that you can no longer access that variable from the process that sent it, so they are actually "transfers" not "copies" or "references"). They are not only here now, but they have pretty stellar browser support (back to IE10 and even safari 5.1).

Node had it's own thing for a while as well, and there are many libraries on top of it to make it more capable or close to the web worker spec if you want. Sadly none of them seem to fully implement the web worker spec with the transferable objects ability, but there's no reason why that can't happen.

Personally I prefer this method MUCH more than just giving you classic multithreading primitives and telling you to not shoot your eye out. Going along with what you said, it's significantly harder to get race conditions when you are either copying everything, or are actually transferring the data to someone else. It seems limiting at first, but I haven't hit anything personally that requires more than that to use 100% of the cores on a system. (the few times i've used it in production situations was setup to basically have the main thread split the data, then transfer them off to worker threads to be processed and either transferred back, or the result collected in the main thread when ready)

That being said, there is some work happening on "SharedArrayBuffers" and Atomics [1] which are the real deal "you'll shoot your eye out" shared memory. And I believe they are well into the standardization process. Personally I'm going to avoid them like the plague, but I know that there are use cases out there that can't be solved with "transferrable objects". Mozilla has an MDN page on SharedArrayBuffer at [2] which is pretty useful.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...

[1] http://tc39.github.io/ecmascript_sharedmem/shmem.html#Atomic...

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

The claim about line 2 executing right after line 1 breaks for any program running in concurrent context. Which is probably every nontrivial program dealing with side effects ever written, does not really matter whether that is C#, C++, JS or bare metal assembly.

> something that I am still mindful of, is that you will NEVER have race conditions, as the entire user code will execute in a single thread

If your runtime (kernel, VM, etc - not "user code") has theoretical possibility to change user memory/variable (call user code) concurrently, there is theoretical possibility to have race conditions. Concurrent runtime must have certain entry points to user code and everything that can be theoretically touched from these entry points must be treated dirty, which can get pretty expansive with complex callbacks. The only way to NEVER* have race conditions is to use polling - explicitly mark memory dirty (semantically in code) between "synchronisation points" having only flags/counters (in my view they are the same) for communication between userland and runtime.

* If we allow for settling time and do not treat situations "read flag --> have flag value flipped --> execute based on old flag value" as race conditions.

If I accept your claims that the distinction is important, and that misconceptions can be damaging, is the actual implication here doing any actual damage? Is what you're talking about relevant to this article or to JavaScript?

The fact of the matter is that JavaScript was born with first class functions and event handlers, from the very beginning. In the browser, the majority of projects of any substantial size involves using event handlers, AJAX requests and requestAnimationFrame/setTimeout, among other things.

Even on NodeJS, if you're serving something you're using async. If you're interacting with process events, you're using async. If you're reading files, you're using async. (even the sync functions for files wrap async ones) If you've downloaded anything from NPM, you're almost certainly using async. There is next to nothing that is pure synchronous.

Even if what you said is true, you are suggesting a misconception that could be damaging in the name of avoiding damaging misconceptions. Almost all real world usage of JavaScript uses async code & callbacks, and to split hairs over whether async is native to the language for the sake of beginners is to mislead them.

> A lot of beginner guides to various programming languages make this mistake of associating a certain property with a language as if it's inherent. In this case, async code - while sold as a main feature of the NodeJS platform - is in no way exclusive to, or even an inherent part of, Javascript/ES the language.

Exclusive no, but considering JS's original environment and constraints it is in fact pretty inherent. `setTimeout` is part of the core language and has been for a long time, a blocking `sleep` is not.

Actually `setTimeout` is not part of the core language, it's a Web API.

I think the point they were trying to make is that all JS is almost always used with a run loop.

Whereas Ruby and Python are often used without a run loop.

> I think the point they were trying to make is that all JS is almost always used with a run loop.

Sure, but criticising a rant about the propogation of misconceptions by propogating a misconception seems like a self-undermining position :)

> This may seem a nitpick, but I think it's an incredibly important distinction for beginners (or at least, I think it's incredibly important not to mislead beginners into believing in this limitation early on).

No, I think it's very important, maybe even more important for some of us old dogs still marvelling at having virtual SMP in a desktop rig. While it might be easier to teach people new to programming the old model of a series of instructions that goes step by step, I feel it's also important to express that statements may get run out of order, even in languages not designed for it (optimizing compilers have been doing this forever).

> While bombarding beginners with a lot of info at the start is a bad idea, these kind of misconceptions can be very damaging. They leads to a very narrow idea of what's possible with (any) languages in general, and uninformed decisions on what to learn as a result.

It's also dangerous to always assume that statement A will execute before B just because that's how they appear in the code. Getting people acquainted with the tools necessary to properly do "threading" early on would be a step in the right direction.

I'm not too sure but you might have misinterpreted my comment?

I was saying one shouldn't tell beginners that JS is inherently async and other languages are never async.

Are there JS runtimes that are primarily synchronous? Certainly not any popular/widely used ones. Asynchrony is for all practical purposes a property of JS.

I'm not even sure there's an implementation that could do even the most common synchronous operation.

Like opening a socket, sending data, and blocking on the response.

I'm not sure if you mean implementation of JS or of something that supports executing JS. If you start with the bare interpreter and add say, global functions, through the interpreter's extension API, they CAN be synchronous. You COULD produce a JS environment this way and run scripts in it. Your extensions could include synchronous usage of sockets. Your programs in this environment would be synchronous. Writing a decent web server in that environment would be a challenge.

We're saying the same thing. The nature of the environment is slanted to async, thus, commonly available runtimes don't have much functionality that is synchronous.

You can find some of it, but it's the exception, not the rule.

Yes, you can build something specific, just as you can leverage async libraries in languages where it's not the common pattern.

Maybe not, but it's irrelevant. The point I was making is that the async features are platform APIs, they have no inherent attachment to the language.

And I personally think not knowing the distinction between the language and APIs provided to it is extremely limiting and misleading for someone approaching learning programming (it was for me, I wish this had been clearer to me earlier).

>Maybe not, but it's irrelevant

I'm not sure it is. What's available, without custom work on your own, drives the ecosystem.

I can build an asynchronous application with PHP, but there's not much established practice, existing tools, shared learning and so forth. And, whatever I build that way is limited to an audience that will go out of their way to build my custom php interpreter.

You can run Javascript on the JVM with Rhino and Nashorn. There you have access to all the classical synchronous Java APIs - and you need to care about synchronization and real multithreading, which is not really javascripty.