Introducing vibe.d!

[Sönke Ludwig]

Am 27.04.2012 10:01, schrieb Nick Sabalausky:
> Sounds great! And the site's very speedy :)  I'm especially excited about
> this:
>
> "(Work-in-progress) An integrated load balancer is able to dynamically
> compile, run and test new processes before switching them live after the
> code has been modified."
>

Me too, me too, it would have saved my ass last night when the server 
went down ;)

> A few questions:
>
> - Does the web framework work with other web servers, or is it tied to the
> built-in server?

You can put it behind an nginx reverse proxy (beginning with the new 
v1.2 that supports HTTP/1.1).

You could also just use everything except the HTTP server component and 
use classic CGI/FastCGI to communicate to the Web server. However, there 
is currently no FastCGI server built in, so something like libfcgi would 
have to do.

>
> - I don't suppose you have a feature comparison between the built-in server
> and Nginx? Is it one o' them fancy C10k servers? (Not that I'm likely to
> ever get that kind of traffic outside of a DDoS attack ;) )

We still have a more comprehensive benchmark on the table but it seemed 
to get along happily with about 60MB of RAM usage during a C10k test. 
The average request time went down to about 6s if I remember correctly. 
The test was using a dual-core Atom server over a WiFI connection so the 
results may have been skewed a litte.

I'm also planning to implement a core driver based on libuv in addition 
to the current libevent based one, which should gain a little more 
performance.

In terms of HTTP/1.1 implementation it is most importantly lacking 
multipart form uploads (will be added shortly). Otherwise the protocol 
supports most HTTP features. I'll put a more detailed comparison on my 
TODO list.

>
> - Why "static this"? Seems like a strange choice since it'll run before the
> main that (I assume) vibed automatically provides - and in an undefined
> order relative to all other module ctors.
>

The order of module constructors should be defined to be a valid order 
wrt. the import tree right?

The main reason is to have a lean and mean way to write small 
applications. A default main() is compiled in which handles command line 
parsing, connection to a load-balancer/reverse proxy etc.

However, it is also possible to just implement a custom main() and start 
from there - you just have to include vibe.vibe instead of vibe.d so 
that the built-in main() is not compiled. I will put an example on the 
website later.