[justplay]

    >Node was created by software developer Ryan Dahl 
    as a way of building and running entire online applications
    with JavaScript—the standard programming language for writing 
    code that runs in your browser.

Really? I thought that they intentionally choose javascript because it doesn't have any features like threading.

   > The massively popular programming framework Ruby on Rails, 
   for instance, is still sponsored by its creator, a company called Basecamp.

Basecamp isn't happy to the direction that ruby on rails is going, but they accept it. [1]

[1]: https://www.youtube.com/watch?v=lBfVxBj61z0&feature=youtu.be...

[drderidder]

It's a widely held misconception that JS doesn't have threading. User code executes in a single thread, but asynchronous tasks are managed by a thread pool (libuv in node). Because the multi-threading is hidden with asynchronous calls, the user doesn't need to worry about it, which is why many people say JS is single-threaded. In fact worker threads execute async tasks behind the scenes; it's a very nice feature of the event-loop architecture.

[flebron]

You may be speaking of a particular implementation or engine. JS, the language, has no such concept of a "thread". The standard describes execution of a valid program as linear. Libraries may add functions such as event listeners or threading or sockets, but these are not part of the language.

And yes, to be pedantic, by JS I'm refering to ECMAScript, or ECMA-262. If by JS you mean JavaScript the implementation by Mozilla, then Node doesn't use that anyway :p

[joshuacc]

Well, there are Web Workers, which are basically threads. http://www.html5rocks.com/en/tutorials/workers/basics/

But it appears that it's part of the WHATWG HTML spec rather than ECMAScript, which is a bit weird.

[jerf]

Web Workers are closer to "processes" in the Erlang sense of the term. They're walled off fairly extensively from the rest of the JS runtime that spawned them because that is pretty much the only good way to backport threading onto a language that wasn't designed with it in mind from the beginning.

Languages like C which had them bodged on years later, well, I'd call that a bad way to do it. It worked for the time but there's a reason why we are all fleeing that implementation of threading and it still stains the entire idea of "multithreading" decades later.

If JS is ever going to get threading, the best case scenario is for it to look like Perl or PHP's efforts... years and years of implementation work to get to something that pretty much everybody recommends you still just stay away from. And Perl and PHP were trying to integrate threading into just one runtime each, and without a browser connected at the hip with its own ideas about threading embedded into decades of code. I would not hold your breath for "true" JS threads anytime soon.

[pfraze]

That's because it's a Web platform API, not a language feature.

[pan69]

Timers are sort of threads..

[pan69]

Let me know if you disagree... Don't just hide behind a down vote...

[stepstep]

Really? I've never seen any synchronization code (e.g., locks) in JavaScript. If multiple threads can execute async tasks in parallel, doesn't that mean JavaScript needs synchronization primitives? Most JS code I've seen in the wild relies implicitly on the single-threaded assumption—that only one callback (for example) will run at a time.

[youtrin]

Say you wanna make an HTTP request.

What node will do is kick off the process (dns, grab a socket, connect tcp, write the header, wait for response etc.)... but it won't wait for any of this to finish, it just starts it on another thread. That thread doesn't need any JS-level synchronization because it has nothing to do with JS. Furthermore, you can kick off multiple requests like this in parallel.

When a request is done and has data to pass back, the external thread will queue up a V8 event. When V8 is free and is ready for the next event, it will see the finished request and trigger your callback with the data. When you're done handling that data (in Javascipt), V8 will wait for the next event and so on.

So you see, it's parallel but doesn't need any JS synchronizatioon.

[klibertp]

> the external thread will queue up a V8 event

> So you see, it's parallel but doesn't need any JS synchronizatioon.

I don't know much about V8/Node internals, but I think we can regard the queue as a synchronization primitive? Granted, from what you say it's not in JS, but it's there, so at least some JS implementations need synchronization.

[elmin]

This is not done in parallel. Only one block of javascript is being executed at any given time. There is also no concept of preemption, if your function runs forever no other other events or callbacks will be handled.

[nostrademons]

How much time in a typical Node application is spent executing JS, vs. how much is in the C++ networking code?

[extropy]

JavaScript does not share memory between threads. No shared memory - no need for sync code. Instead it uses message passing and event loop to do the sync for you.

The way it's implemented is similar to Windows 3.x times - collaborative multitasking. Then there is no code to execute in your thread, an background event loop runs, listens for messages from another threads and calls appropriate callback function in your thread.

This design has the benefit of being simple to do simple stuff. And near impossible for more complex multithreaded algorithms that require shared memory.

[rpedela]

Sorta. What you say it true, but it is also true that Node isn't multi-threaded because the user does not have access to that thread pool. The user cannot create their own threads to do CPU work unless they go into C/C++ land. In other words, only I/O is multi-threaded so if you need to do expensive CPU work then you need to spawn a process which can be cumbersome.

[drderidder]

Just to clarify this was responding to:

> I thought that they intentionally choose javascript because it doesn't have any features like threading.

I wanted to point out that JS doesn't preclude parallelism, it's just implemented as async calls. It would be more correct to say the runtime owns the thread pool. Thanks to other commenters for making the distinction.

[nostrademons]

Does each thread get a separate V8 interpreter? I was pretty sure that V8 has a GIL (at least at the Isolate level), just like Python and (Matz) Ruby, and so how do they handle lock contention between multiple threads?

[youtrin]

No, because the I/O threads never enter JS land (V8); they just dump their data for the main V8 thread to pick up.

And yes you are correct that V8 effectively has a GIL for its Javascript execution (though V8 does actually run other threads in the background for profiling).

[discreteevent]

But for web workers there are two threads executing JavaScript in parallel no? However they cannot share state. They can only communicate via messages. It's basically the actor model and it does demonstrate how effective and safe it can be (although Erlang already demonstrated that in spades). No pure FP needed! (although in theory I suppose you could deadlock with two workers waiting on each other for a message)

[i_am_ralpht]

Is that a language feature or a runtime/library feature though?

[zabil]

The language is designed to handle events/messages because it runs on single thread in the browser. As far as I know, you cannot spawn threads.

The runtime/library does it under the hood.

[masomenos]

DHH said there are things about the "large tent" aspect of rails that are annoying. That's not the same thing as being unhappy with the overall direction of the project.

[mercer]

    > Really? I thought that they intentionally choose javascript because it doesn't have any features like threading.

Yes. I recall Ryan Dahl saying that he first looked at other languages, but he picked JS because it simply didn't have a server-side presence, and so he could 'define' the ecosystem to be async. And it was pretty fast what with the V8 improvements. The benefit of using js for both back- and front-end was just a nice extra.

[zackmorris]

While I think abandoning threading was originally a good move because it spawned (no pun intended) new methods of chaining callbacks together, I'm concerned that there is really no way out of callback hell by way of callbacks.

So I'm wondering if Node.js, Io.js or both will embrace coroutines, yield and generators. The real danger of threads was always shared memory, not so much simultaneous execution. I'm hoping that we'll start to see Go, Erlang and even shell-style piping of data through predictable, testable and debuggable threads of execution begin to replace callbacks.

If anyone has a general approach for converting callbacks to use coroutines and yield in Javascript, I'd be very eager to hear it. Also the problem of how to enforce scope in Javascript, to prevent sharing state between coroutines.

[notduncansmith]

If you want to get out of callback hell, I Promise you'll enjoy this library called Bluebird.

[justplay]

`Bluebird` looks good, i gonna try it out. thanks.

[jerf]

Thing is, if you want Go- or Erlang-style piping of data, well, Erlang and Go are right there... and both written from day 1 to support those use cases, rather than bodging them onto a language ten years later....

[mcantelon]

One of the main reasons for picking JS was that it didn't have a standard library filled with non-async code that would end up slowing apps down if used. Node folks were forced to create an ecosystem of modules from scratch and made them async.

[rquantz]

The relevant question in the linked video starts at around 11:12