Introducing vibe.d!

[Sönke Ludwig]

Am 29.04.2012 06:18, schrieb Martin Nowak:
> Very nice to see that someone took the async/Fiber idea that far.
>
> Some observations:
> - Wouldn't wrapping code in "void main()" instead of "static this()"
> make better front page examples.

The static this() pattern is mainly there to appeal to users of similar 
systems in script languages, where you don't have a main function at all 
and just happily hack away. For larger projects it doesn't make a 
difference but for small projects it can actually be quite convenient.

Maybe it would be a good idea to place a prominent example of how it's 
possible to define your own main() to gain additional control.

> - It would be interesting to know what made you write your own
> Stream/JSON implementations.

Stream has a number of additional functions or parameters such as 
leastSize() that are required or extremely convenient in this context. 
Also to avoid dragging in something like std.stream.File which has 
sychronous behavior and would block the event loop without anyone 
noticing it until the resulting bad performance under high-load 
conditions shows.

The reasons for writing an own Json implementation is that the interface 
of std.json is.. well.. nice if you write something in C. The 
implementation in vibe tries to let Json seem like a natural dynamic 
type of the language as far as it makes sense. The std.json parser can 
also only parse string buffers and I wanted to have something that can 
easily be used to work efficiently on a stream. Support for pretty 
printing was another reason (would of course also easy to add on top of 
std.json).

> - I think there is some interest in having the HTTP handling and the
> templates in a separate library.

My considerations are that if you don't use the HTTP/... parts, it will 
neither occupy space in your app, nor will it drag in any additional 
dependencies. That separate library would basically be vibe.core and 
vibe.stream vs. the rest of modules. And dependency-wise they are 
already separate (core and stream have no outside dependencies to the 
library).

If on the other hand you wanted to use the HTTP/... stuff together with 
other libraries in a blocking, non-fiber environment, it would also just 
work - all operations are also working and blocking outside of the event 
loop.