www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Who said that Node.js scales ?

reply deadalnix <deadalnix gmail.com> writes:
Ha yes, it is on the website.

You'll find here an article about that, and how Go do much better 
because of goroutines :

http://blog.bitcartel.com/2012/05/nodejs-cpu-blocking-thing.html

I'd be very interested to know how D compare to that, for example with 
vide.d ?
May 22 2012
next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"deadalnix" <deadalnix gmail.com> wrote in message 
news:jpgn05$29v4$1 digitalmars.com...

 Ha yes, it is on the website.

 You'll find here an article about that, and how Go do much better because 
 of goroutines :

 http://blog.bitcartel.com/2012/05/nodejs-cpu-blocking-thing.html

 I'd be very interested to know how D compare to that, for example with 
 vide.d ?


I keep hearing about this popular "node.js" thing, so I finally looked it up 
just now. JavaScript on the server-side?!? WTF?!?! Like having PHP on a 
server isn't *enough* pain, now they gotta add in the second-worst language, 
too?

That's a great article, though. Interesting, intelligent and very 
well-written.

I'm very curious how the vibe.d author would respond to the argument against 
embedded HTTP servers.
May 22 2012
next sibling parent reply Pragmatix <pragmatix orange.fr> writes:
Am 22.05.2012 21:59, schrieb Nick Sabalausky:

 I'm very curious how the vibe.d author would respond to the argument against
 embedded HTTP servers.


Ask him on :

news.rejectedsoftware.com
May 22 2012
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 22.05.2012 22:38, schrieb Pragmatix:

 Am 22.05.2012 21:59, schrieb Nick Sabalausky:

 I'm very curious how the vibe.d author would respond to the argument
 against
 embedded HTTP servers.


 Ask him on :

 news.rejectedsoftware.com


Just wanted to note that posting on the DFeed forum was not possible 
until now - I had to do some additional configuration and there is still 
some stuff missing, but basic posting works:

http://news.rejectedsoftware.com/
May 23 2012
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 23 May 2012 at 13:42:34 UTC, Sönke Ludwig wrote:

 http://news.rejectedsoftware.com/


Looks like it runs on Node.js :)
Why so slow?
May 23 2012
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 23.05.2012 16:46, schrieb Kagamin:

 On Wednesday, 23 May 2012 at 13:42:34 UTC, Sönke Ludwig wrote:

 http://news.rejectedsoftware.com/


 Looks like it runs on Node.js :)
 Why so slow?


;)

Actually, I'm not sure. It runs fast for me at least now and it could be 
that I was still doing maintainance stuff on the server at that time. Is 
it still slow now?
May 24 2012
prev sibling next sibling parent Pragmatix <pragmatix orange.fr> writes:
Am 22.05.2012 21:59, schrieb Nick Sabalausky:

 I'm very curious how the vibe.d author would respond to the argument against
 embedded HTTP servers.


Regarding performance.. simply have a look and scroll down..

https://github.com/rejectedsoftware/vibe.d/issues/38
May 22 2012
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 22 May 2012 at 19:59:34 UTC, Nick Sabalausky wrote:

 "deadalnix" <deadalnix gmail.com> wrote in message
 news:jpgn05$29v4$1 digitalmars.com...

 Ha yes, it is on the website.

 You'll find here an article about that, and how Go do much 
 better because of goroutines :

 http://blog.bitcartel.com/2012/05/nodejs-cpu-blocking-thing.html

 I'd be very interested to know how D compare to that, for 
 example with vide.d ?


 I keep hearing about this popular "node.js" thing, so I finally 
 looked it up
 just now. JavaScript on the server-side?!? WTF?!?! Like having 
 PHP on a
 server isn't *enough* pain, now they gotta add in the 
 second-worst language,
 too?


I will only use node.js if I am ever forced to do so.

There isn't a single node.js feature that it is not available in 
more
mature runtimes/OS.

It is only a mean for cool kids that are only able to use 
JavaScript, to
try to code server side applications.

I'll give it one, max two years until the fad wears off.

..
Paulo
May 22 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Paulo Pinto" <pjmlp progtools.org> wrote in message 
news:dpkzrthivflxyuoxoxww forum.dlang.org...

 I will only use node.js if I am ever forced to do so.

 There isn't a single node.js feature that it is not available in more
 mature runtimes/OS.

 It is only a mean for cool kids that are only able to use JavaScript, to
 try to code server side applications.


Nah, "cool" kids make the browser do everything. ;)


 I'll give it one, max two years until the fad wears off.


I'd like to agree with that, but I'm much more pessimistic. After all, look 
at the longevity PHP and Flash ended up having. On the web, the worse the 
technology, the more it will be adopted. That seems to be the way it 
generally works. Give it five, maybe ten years, then we'll start seeing a 
trend toward articles like "Node.js: A fractal of bad design"

My bet is the only thing that will squeeze node.js out of the way will be 
the next big dumb idea. I hope I'm wrong.
May 22 2012
prev sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
 I keep hearing about this popular "node.js" thing, so I finally looked it up
 just now. JavaScript on the server-side?!? WTF?!?! Like having PHP on a
 server isn't *enough* pain, now they gotta add in the second-worst language,
 too?

 That's a great article, though. Interesting, intelligent and very
 well-written.

 I'm very curious how the vibe.d author would respond to the argument against
 embedded HTTP servers.


Is that argument mentioned in the article? I didn't see it.. but maybe I 
skimmed over it too fast.

In general, the current model is single-threaded I/O + worker threads + 
multiple processes behind a load balancer. However, it's planned for 
v1.0 to support distribution of connection handler fibers to a thread 
pool, so that explicit worker threads are not strictly necessary 
anymore. This would be the Go model in principle.
May 22 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 23/05/2012 08:35, Sönke Ludwig a écrit :

 I keep hearing about this popular "node.js" thing, so I finally looked
 it up
 just now. JavaScript on the server-side?!? WTF?!?! Like having PHP on a
 server isn't *enough* pain, now they gotta add in the second-worst
 language,
 too?

 That's a great article, though. Interesting, intelligent and very
 well-written.

 I'm very curious how the vibe.d author would respond to the argument
 against
 embedded HTTP servers.


 Is that argument mentioned in the article? I didn't see it.. but maybe I
 skimmed over it too fast.


No that is stated in the article, but not the main point of it.


 In general, the current model is single-threaded I/O + worker threads +
 multiple processes behind a load balancer. However, it's planned for
 v1.0 to support distribution of connection handler fibers to a thread
 pool, so that explicit worker threads are not strictly necessary
 anymore. This would be the Go model in principle.


I'd love to see that. I think vide.d have a bright future !
May 23 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Tue, 22 May 2012 20:47:33 +0200, deadalnix <deadalnix gmail.com> wrote:


 Ha yes, it is on the website.

 You'll find here an article about that, and how Go do much better  
 because of goroutines :

 http://blog.bitcartel.com/2012/05/nodejs-cpu-blocking-thing.html

 I'd be very interested to know how D compare to that, for example with  
 vide.d ?


I'd say that this is a very weak argument. Considering the uptime of a
server application there is plenty of time to compile javascript to very
efficient code.
Where the JIT does not suffice they can go the FFI route.
The scary part of Node.js is using callbacks to structure control flow.
May 23 2012