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

Interview with Ryan Dahl, Creator of Node.js

mappingthejourney.com

Post reply on HN
Print view View original

71–80 of 235 posts

Re: Interview with Ryan Dahl, Creator of Node.js

#71

Post by jondubois »

s_kilk wrote: post #2

> That said, I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node. It was the realization that: oh, actually, this is not the best server side system ever. Really interesting. I can imagine others would refuse to give up on the thing they'd worked so hard on. But Dahl has the self-awareness to just step back an…

He doesn't give any specific reason why he thinks that Go is better. I've used both Go and Node.js and I came to the opposite conclusion.

I'm not a huge fan of Goroutines spawning threads in the background. I think that spawning threads and processes should be explicit because there is a big performance penalty when multiple threads have to share a CPU core because of context switching.

With Node.js, you have more control over the process count so you can minimize the amount of CPU context switching that happens by making sure that each process gets its own CPU core.

That said, I do think that on a conceptual level, Go feels cleaner than Node.js... But since async/await was introduced I feel that Node.js has the upper hand again.

Re: Interview with Ryan Dahl, Creator of Node.js

#72

Post by sporkland »

cmiles74 wrote: post #61
bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

I think the only new thing that node.js brought to the table was a nice way to run Javascript on the server. Node.js doesn't use threads, but as you said, their event-driven non-blocking I/O model wasn't new (Python had Twisted and Java had Netty). In addition, Java has had non-blocking I/O (in the form of the nio) packages for quite some time. In my opinion, Node.js became popular because people wanted to run Javasc…

I remember distinctly at the time that the fact that there was excitement around node.js because it was built from the ground up to use evented IO exclusively. All the libraries, the core runtime etc. People in other languages (C) were for sure doing it, but not in the holistic way node was. As opposed to java and python where you needed to avoid using the library calls that were blocking.

Re: Interview with Ryan Dahl, Creator of Node.js

#73

Post by cdelsolar »

nulagrithom wrote: post #68
bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

On that note, coming back from node.js has been a really frustrating experience for me. I want to scream every time somebody suggests threading as a solution to non-blocking database calls and HTTP requests. It's made me painfully aware of how often parallelism is suggested in place concurrency. C# in particular does a great job at conflating concurrency and parallelism. Both fall under the same Task namespace and it…

but why? Go's model is perfect. They're not real threads, it's basically very similar to Node, except that you can write code without a mess of callbacks and it's easier to reason about...

Re: Interview with Ryan Dahl, Creator of Node.js

#74

Post by dasmoth »

tree_of_item wrote: post #65
dasmoth wrote: post #29

Earlier quoted context omitted.

Potentially a better term is "isomorphic", a label which is specifically applied to setups where you run the same rendering code client-side and server-side. That's still a comparatively new concept, at least as something that's actively supported by frameworks and reasonably straightforward to implement.

That's an awful term because it has nothing to do with the actual meaning of the word "isomorphic".

I'm inclined to agree, but it seems to have stuck, and is at least more specific than "server side rendering".

Re: Interview with Ryan Dahl, Creator of Node.js

#75

Post by z3t4 »

cmiles74 wrote: post #61
bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

I think the only new thing that node.js brought to the table was a nice way to run Javascript on the server. Node.js doesn't use threads, but as you said, their event-driven non-blocking I/O model wasn't new (Python had Twisted and Java had Netty). In addition, Java has had non-blocking I/O (in the form of the nio) packages for quite some time. In my opinion, Node.js became popular because people wanted to run Javasc…

You can write JavaScript in classic ASP, there are many server JavaScript, but they are serial/blocking, and NodeJS is async/non blocking.

Re: Interview with Ryan Dahl, Creator of Node.js

#78

Post by turtlebits »

bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

As a Python/Ruby web dev, exactly this. Dealing with uwsgi/passenger was so painful to me. And asyncio in python3 still boggles me.

Re: Interview with Ryan Dahl, Creator of Node.js

#79

Post by sreque »

bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

Node.js brings callback hell to the serverside world of threads and we're supposed to be grateful? It's like you don't know the history of computing. Callback-based code was the original programming model in UNIX dating back decades! Threaded code came about because it's far easier to write it than callback-based code.

The ONLY reason to do callback-based code is for performance reasons: for network-IO-heavy apps there is less OS-level overhead from managing thousands of connections with a few threads using the OS-provided non-blocking I/O operations than managing a connection per thread. Even then, if you actually want to do better than connection-per-thread, you have to avoid the POSIX API for non-blocking I/O and use whatever OS-specific API is available for better performance (epoll, kqueue, or completion ports).

The greatest joke of all though is that Node.js is dirt slow because Javascript is dirt-slow. Yes, you may be able to invent some microbenchmark where Node.js looks good, but the only reason it does in that benchmark is because the Node.js app is spending 99.9% of it's time executing code in a C library. Any real-world Node.js app is going to be slow because Javascript in general, even on V8, is anywhere from 10-100x slower than C or even well-written Java.

And worst of all, Node.js is single-threaded! If you want to scale onto all your cores you have to go multi-process, which is an incredible pain in the general case. So, you switch to a runtime and framework that forces a more difficult way of programming on you (callback hell) but which is better for general networking performance, but you use a dirt-slow, single-threaded runtime while doing so. You are basically ending up with the worst of both worlds, and any decent development team will run circles around you in performance and productivity with just about any other backend stack.

Re: Interview with Ryan Dahl, Creator of Node.js

#80

Post by 52-6F-62 »

turtlebits wrote: post #78
bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

As a Python/Ruby web dev, exactly this. Dealing with uwsgi/passenger was so painful to me. And asyncio in python3 still boggles me.

I like Python a lot, and use it for a number of things even though my position doesn't require it where I work, but uwsgi was the thing that kept steering me away from it. I'll probably make myself master it at some point, but it just felt fumbling at first take and left a bad taste.
Post reply on HN