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 ?

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

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

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

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

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

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

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 !

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/

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?