Live data from Hacker News

Node.js, a popular tool for building modern internet services, has split in two

wired.com

131–140 of 166 posts

Re: Node.js, a popular tool for building modern internet services, has split in two

#131

Earlier quoted context omitted.

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 t…

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 Mo…

Timers are sort of threads..

Re: Node.js, a popular tool for building modern internet services, has split in two

#132

The new repository: https://github.com/iojs/io.js/ The new contributors: https://github.com/iojs/io.js/graphs/contributors Joyent really fucked up.

The "new contributors" link you provided uses commits from before the fork, so it doesn't really have any information.

Re: Node.js, a popular tool for building modern internet services, has split in two

#133
post #20
post #5

Earlier quoted context omitted.

But it's true that Node is losing traction.

I can only speak from the perspective of my company. We had quite a few pro-node people. They wrote services in node. All of those node services have since been rewritten in Go by the formerly-pro-node people. Go has been much more manageable and powerful.

As I said on reddit as well, I'd really like to hear from someone with a year of serious Node experience and then a year of serious Go experience who ended up wanting to go back to Node, for anything other than perhaps a library than only Node had. While the Internet is large and any crazy criterion will match somebody, somewhere, my strong suspicion is that this is not a large set of people. I suspect it's more-or-less a one-way door.

Re: Node.js, a popular tool for building modern internet services, has split in two

#135

>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 cr…

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

Re: Node.js, a popular tool for building modern internet services, has split in two

#136

Earlier quoted context omitted.

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 t…

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.

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.

Re: Node.js, a popular tool for building modern internet services, has split in two

#137

>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 cr…

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.

Re: Node.js, a popular tool for building modern internet services, has split in two

#138

>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 cr…

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 t…

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.

Re: Node.js, a popular tool for building modern internet services, has split in two

#139

The new repository: https://github.com/iojs/io.js/ The new contributors: https://github.com/iojs/io.js/graphs/contributors Joyent really fucked up.

The "new contributors" link you provided uses commits from before the fork, so it doesn't really have any information.

Do you know who the 4 developers mentioned are? isaacs probably is the NPM one.

Re: Node.js, a popular tool for building modern internet services, has split in two

#140
post #95

Earlier quoted context omitted.

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?

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

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)
Post reply on HN