5 ms·

> 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 and so

> 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 and so on down the file. As you will learn, JavaScript is different. 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. 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). Another common example was, up until recently, that Javascript "wasn't powerful enough" to do filesystem access, hardware operations, etc. A simple side-effect of the environment the language was most commonly executing in (the browser) was turned into an inherent limitation of the language in order to "simplify things for beginners". 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.

masklinn 10y ago
> 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.
- vmasto 10y ago
  Actually `setTimeout` is not part of the core language, it's a Web API.
  - srssays 10y ago
    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.
    - richmarr 10y ago
      > 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 :)
  - deleted 10y ago
    [deleted]
hashkb 10y ago
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.
- tyingq 10y ago
  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.
  - cardiffspaceman 10y ago
    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.
    - tyingq 10y ago
      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.
- lucideer 10y ago
  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).
npsimons 10y ago
> 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.
- lucideer 10y ago
  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.
dahart 10y ago
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.
novaleaf 10y ago
> 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).
- MrDosu 10y ago
  I agree. Asynchronous programming is orders of magnitude easier to grasp than concurrency. Especially in low lock scenarios. Interlocked.Increment(yourPost) :P
- antihero 10y ago
  You can still have race conditions anywhere IO is concerned, just not at a thread level (because no threads).
  - simplify 10y ago
    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.

masklinn 10y ago

> 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.

vmasto 10y ago
Actually `setTimeout` is not part of the core language, it's a Web API.
- srssays 10y ago
  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.
  - richmarr 10y ago
    > 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 :)
- deleted 10y ago
  [deleted]

hashkb 10y ago

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.

tyingq 10y ago
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.
- cardiffspaceman 10y ago
  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.
  - tyingq 10y ago
    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.
lucideer 10y ago
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).

npsimons 10y ago

> 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.

lucideer 10y ago
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.

dahart 10y ago

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.

novaleaf 10y ago

> 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).

MrDosu 10y ago
I agree. Asynchronous programming is orders of magnitude easier to grasp than concurrency. Especially in low lock scenarios. Interlocked.Increment(yourPost) :P
antihero 10y ago
You can still have race conditions anywhere IO is concerned, just not at a thread level (because no threads).
- simplify 10y ago
  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.