Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js is Backwards

blog.ankurgoyal.com

Post reply on HN
Print view View original

61–70 of 90 posts

Re: Node.js is Backwards

#61

Post by jessedhillon »

Volpe wrote: post #41
sausagefeet wrote: post #31

Earlier quoted context omitted.

I see the "sharing code" claim a lot but I haven't really seen it substantiated. Seems like you write a few little functions but it's not like you sharing the same framework which would be the real benefit.

> Seems like you write a few little functions... Seriously? A very common problem in web apps is validation logic is usually duplicated in JS and Server side language. Node allows the same logic to be used in both cases. These are not a 'few little functions'. Validation is a central part of most business applications. Given the potential to template html with javascript, and to code exclusively in javascript. You co…

In my experience, most validation on the server is a superset of what's required on the client (or disjoint).

For example, validating a user's name on the client merely checks if the name's length is in a certain range and doesn't contain invalid characters. On the server it requires a query to the database -- possibly more.

I also reject the notion that there is a significant context switch involved in going from one language to the other.

Re: Node.js is Backwards

#62

Post by jessedhillon »

akdubya wrote: post #56
alnayyir wrote: post #32

Earlier quoted context omitted.

>Using the same language at both the client and server end has some serious benefits. The functionality implemented is mutually exclusive. This canard needs to die.

I'm working on a distributed app that shares code between the client and server, and there are already a multitude of open-source libraries that are designed to run in any JS environment.

That doesn't mean it's useful to do so, or that there are significant advantages to be gained from doing so.

Re: Node.js is Backwards

#63

Post by alnayyir »

jessedhillon wrote: post #62
akdubya wrote: post #56

Earlier quoted context omitted.

I'm working on a distributed app that shares code between the client and server, and there are already a multitude of open-source libraries that are designed to run in any JS environment.

That doesn't mean it's useful to do so, or that there are significant advantages to be gained from doing so.

This.

Also I appreciate you picking up where I left off, I've been making a major lifestyle change and am almost completely sapped of energy.

This has improved my concision considerably wrt code and conversation.

Cheers, let me know if you find yourself in SF, I'll get you a round on me.

Re: Node.js is Backwards

#64

Post by [deleted] »

jessedhillon wrote: post #62
akdubya wrote: post #56

Earlier quoted context omitted.

I'm working on a distributed app that shares code between the client and server, and there are already a multitude of open-source libraries that are designed to run in any JS environment.

That doesn't mean it's useful to do so, or that there are significant advantages to be gained from doing so.

[deleted]

Re: Node.js is Backwards

#65

Post by aufreak3 »

It looks to me like all this debate has no observable consequence on the respective programming communities. Node folks will program the Node way and love it and Erlang folks will program the Erlang way and love it. The creators of neither are trying to woo the other and they perfectly well understand operationally where each system stands.

Re: Node.js is Backwards

#66

Post by hannesw »

I think the opinions expressed in this article are valid.

However, I don't think the inability of current JavaScript to do async I/O without callbacks is Node's biggest problem. As others have said, it works for smaller projects (and even has some geek appeal). And as Havoc Pennington and Dave Herman have explained, generators (which are coming with ECMAScript Harmony) and promises will eventually provide a very nice solution. So Node has a path to grow out of the callback model without giving up its single threaded paradigm.

http://blog.ometer.com/2010/11/28/a-sequential-actor-like-ap...

http://blog.mozilla.com/dherman/2011/03/11/who-says-javascri...

The bigger problem (which I don't see getting solved anywhere down the road) is the lack of preemptive scheduling, which is available in Erlang or on the JVM. What you see under high load with Node is that latency is spread almost linearly over a very wide spectrum, from very fast to very slow, whereas response times on a preemptively scheduled platform are much more uniform.

http://jlouisramblings.blogspot.com/2010/12/differences-betw...

And no, this is something that can't be solved by distributing load over multiple CPU cores. This is problem really manifests itself within each core, and it is a direct consequence of Node's single threaded execution model. If anybody knows how to solve this without resorting to some kind of preemptive threading I'd be very curious to hear about it.

Re: Node.js is Backwards

#67

Post by weixiyen »

alnayyir wrote: post #49
benatkin wrote: post #47

Earlier quoted context omitted.

http://news.ycombinator.com/item?id=1088699

That's not their backend, it's just servicing a front-end feature.

It's doing what normally Erlang would have been used for, which answers the original question. It's a node.js deployment, and very early version one at that. I'm not really sure what your point is.

Re: Node.js is Backwards

#68

Post by davidhollander »

ankrgyl wrote: post #44
davidhollander wrote: post #39

> Node.js’s concurrency mechanisms are simply an approximation of Erlang’s. Lulz? Here's a much simpler explanation: it's a polling server. It's not an intentional approximation of this or that (Erlang), this is just how event loops using select\poll\epoll\kqueue have always worked. Unless you want to do a bunch of extra work and throw in per-core preforking\threading and scrap the libev dependency Node built upon.

Erlang, and other similar efforts like Haskell's forkIO and Python's eventlet/gevent, are also built upon the same fundamentals as libev (and some actually just use libev). But using libev in the way that Node.js does boils down to user-space threads with cooperative scheduling (you yield control every time you make a blocking I/O call). The abstractions that Erlang/Haskell/Python provide let you program in the famil…

>(you yield control every time you make a blocking I/O call)

You're referring to is coroutine vs. continuation passing (callback). This is unrelated to whether you also are also forking into a small number of processes for each core. You can do both. Node simply doesn't yet. Nginx with workers is an example of an asynchronous server that does.

In regards to your link and the coroutine yielding approach: Being able to write psuedoblocking and monkeypatching code is not necessarily a good thing! It encourages you to keep making subrequests sequentially in serial, rather than in parallel as comes natural with using callbacks. It also discourages one from using custom continuation logic such as quorums. Examples of when the yielding approach fails:

- You want to both send and read independently on the same connection without creating multiple coroutines\greenthreads\userthreads per connection.

- You want to continue once 2 of 3 data services have calledback that information was successfully stored

I've written a fast single-core asynchronous server here in Lua without using user space thread yielding that you may be interested in: https://github.com/davidhollander/ox

Re: Node.js is Backwards

#69

Post by bittersweet »

SeoxyS wrote: post #9

Speaking of concurrent programming and parallelism. If you're not into functional programming, check out Apple's Grand Central Dispatch[1] and Objective-C Blocks[2]. Unless you write your own Objective-C http server and run it on Mac OS X Server (it's not that hard, I've done it), this isn't very useful for Web programming. However, if you're comparing the languages / frameworks themselves (you can use all three to c…

I've been hacking away on Obj-C and more specifically MacRuby and did some basic stuff with GCD already, using the async queueing system.

The distributed enumeration sounds interesting, could you point me in the direction of where I can find some more info about that?

Post reply on HN