There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful:

"has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried."

If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding.


Andrei

On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:
> If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding.

Google App Engine is opening up for managed servers using new tech. I know Dart is coming to the managed servers soon. Of course, this is still in limited preview and not for production, but having D on App Engine would be interesting for many reasons.

https://developers.google.com/appengine/docs/managed-vms/

Google Compute Engine is also an option. Building libraries to access the regular cloud services such as Google Cloud Storage and Cloud SQL (replicated MySQL) is not too hard.

https://developers.google.com/compute/
https://developers.google.com/cloud-sql/
https://developers.google.com/storage/

It would also be an opportunity to test the abstraction levels of the current standard library…

Vibe.d is more like a base library for async I/O, networking and concurrency, a full stack WEB framework should be built on top of it which focus on application development and ease of use for newcomers. Sonke has said that too. Vibe.d should focus on performance, networking, and other lowerlevel stuff that D should be really good at. Sonke is already too busy doing his gorgeous work on vibe.d and dub. I think that is what the guy on reddit was complaining, he thought vibe.d should contain everything from a web framework, but didn't find them, thus getting the impression that vibe.d was not complete. Actually vibe.d is just an edge of a triangle in web frameworks. We are lacking the other two pieces.

We need a MVC or whatever framework on top of it. Compared to Java world, there is [Netty](http://netty.io) the networking library and Web frameworks like playframework, vert.x built on top of it.

Currently the only work that is active IFAIK is Rikki's [CMSED](https://github.com/rikkimax/Cmsed), which needs more love.

In [playframework](http://playframework.org), incoming request are send to a cluster of actions in a [Akka](http://akka.io) cluster for computing & business logic. The trio (play, netty & akka) has shown to be very good combination for a web stack.

We have actor models in std.concurrency but only with thread granularity, vibe.d has got a fiber based concurrency model which I think could go in to the standard library, or make its own library. That front needs more manpower. Again, rikki has initiated a port from akka -- [dakka](https://github.com/rikkimax/dakka). I think it is a right way to go.


On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:
> There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful:
>
> "has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried."
>
> If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding.
>
>
> Andrei

On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:
> There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful:
>
> "has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried."
>
> If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding.
>
>

I use vibe.d and I have no idea what that commenter was on about.

> Andrei

Also, in playframework, vert.x and nodejs, they all have a plugin/module system, that people could easily compose plugins to make a website. (I call it plugin because that is what play used to call it, now they all call it a module but that name will easily conflict with D's sourcecode modules). This is a critical mechanism that actually allured developers to contribute to the eco-system.

Plugins are like dub packages in a way, but not exactly. Dub packages are an encapsulation of build packages, which is similar to Java's maven packages. But plugins are components of the web framework, built on top of build packages, but has more application related meaning. So both play and vert.x have separated plugin(in vert.x is called a module) concept from maven package. Vibe.d could have this plugin mechanizem, but Sonke said that it should be the responsibility of a framework on top of it (meaning in that framework, vibe.d would just be a plugin to the framework that web developers would choose to server http requests).

For example, if one designed a user/password plugin, with database access logic (in source folder), login page templates (in view folder) and static js/image/css (in public folder), and this plugin is used, then all resources are treated just as they are manually put into respective folders. While dub packages usually only deals with D code.

You can see playframework's plugin registery here: <http://www.playframework.com/documentation/2.3.x/Modules>

vert.x module's document here: <http://vertx.io/mods_manual.html>, vert.x has a more complicated module design (which not only is a way to group functionalities, but also a deployment node).
its registery here: <http://modulereg.vertx.io/>



On Wednesday, 9 July 2014 at 01:09:10 UTC, Puming wrote:
> Vibe.d is more like a base library for async I/O, networking and concurrency, a full stack WEB framework should be built on top of it which focus on application development and ease of use for newcomers. Sonke has said that too. Vibe.d should focus on performance, networking, and other lowerlevel stuff that D should be really good at. Sonke is already too busy doing his gorgeous work on vibe.d and dub. I think that is what the guy on reddit was complaining, he thought vibe.d should contain everything from a web framework, but didn't find them, thus getting the impression that vibe.d was not complete. Actually vibe.d is just an edge of a triangle in web frameworks. We are lacking the other two pieces.
>
> We need a MVC or whatever framework on top of it. Compared to Java world, there is [Netty](http://netty.io) the networking library and Web frameworks like playframework, vert.x built on top of it.
>
> Currently the only work that is active IFAIK is Rikki's [CMSED](https://github.com/rikkimax/Cmsed), which needs more love.
>
> In [playframework](http://playframework.org), incoming request are send to a cluster of actions in a [Akka](http://akka.io) cluster for computing & business logic. The trio (play, netty & akka) has shown to be very good combination for a web stack.
>
> We have actor models in std.concurrency but only with thread granularity, vibe.d has got a fiber based concurrency model which I think could go in to the standard library, or make its own library. That front needs more manpower. Again, rikki has initiated a port from akka -- [dakka](https://github.com/rikkimax/dakka). I think it is a right way to go.
>
>
> On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:
>> There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful:
>>
>> "has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried."
>>
>> If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding.
>>
>>
>> Andrei

On Wednesday, 9 July 2014 at 01:13:39 UTC, Nick Sabalausky wrote:
> On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:
>> There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful:
>>
>> "has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried."
>>
>> If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding.
>>
>>
>
> I use vibe.d and I have no idea what that commenter was on about.
That commenter is probably a web developer that wants all batteries included.
>
>> Andrei

On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:
> There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful:
>
> "has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried."
>
> If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding.
>
>
> Andrei

There is lots of missing little bits here and their, password hashing functions that use crypt_(C) formated hashes.

There are diet/jade template bugs still, specific major problem being that use of single quotes inside of double quotes when i need to pass strings to js functions inside of js events such as onclick inside a html tag, seems to be broken.

There is not common database interface for sql databases(forgivable actually), but many of the specific database libraries are messy(ddb for example) and they are not any where near api "stable".

Support for mongo is... cute?!, don't get me wrong it has a place, for most apps it would be fine, it is however unusable for the apps i am involved in.

Anything supported within vibe.d itself, is great, well thought out, well written, clean and easy to work with. And vibe.d makes wonderful use of D features in a productive way. vibe.d's documentation could be better.

Having to go outside of vibe.d for anything is often gritty, and that is what keeps me from using it. The oddities of being required to use vibe.d's sockets means libraries have to be ported to the extend of changing that(not hard, but maintaining a changeset from the original authors code is cumbersome if they are not updating the lib, or if you would like to link it from another languages compiled code).

That said if the database libraries could be brought up to snuff, one way or another everything else could be worked around for the most part.

On 9/07/2014 1:09 p.m., Puming wrote:
> Vibe.d is more like a base library for async I/O, networking and
> concurrency, a full stack WEB framework should be built on top of it
> which focus on application development and ease of use for newcomers.
> Sonke has said that too. Vibe.d should focus on performance, networking,
> and other lowerlevel stuff that D should be really good at. Sonke is
> already too busy doing his gorgeous work on vibe.d and dub. I think that
> is what the guy on reddit was complaining, he thought vibe.d should
> contain everything from a web framework, but didn't find them, thus
> getting the impression that vibe.d was not complete. Actually vibe.d is
> just an edge of a triangle in web frameworks. We are lacking the other
> two pieces.
>
> We need a MVC or whatever framework on top of it. Compared to Java
> world, there is [Netty](http://netty.io) the networking library and Web
> frameworks like playframework, vert.x built on top of it.
>
> Currently the only work that is active IFAIK is Rikki's
> [CMSED](https://github.com/rikkimax/Cmsed), which needs more love.

Yes, I do need more help, but really I need Dakka to be made first. Get me Dakka. I'll give you live reloading so to speak.

Same goes with my ASN.1 lib[0]. Give me BER unittests, I'll give you an LDAP client library hooked into Cmsed's authentication mechanism (I haven't been able to find them and its not so simply to go by spec).
Give me a way to work with templates and traits better, I'll give you a fully working UML generator[1].

> In [playframework](http://playframework.org), incoming request are send
> to a cluster of actions in a [Akka](http://akka.io) cluster for
> computing & business logic. The trio (play, netty & akka) has shown to
> be very good combination for a web stack.

I have an evil idea on how to do this via Dakka actually, in fact I'm thinking that we could even use it for load balancing. Not to mention live updating during production!

> We have actor models in std.concurrency but only with thread
> granularity, vibe.d has got a fiber based concurrency model which I
> think could go in to the standard library, or make its own library. That
> front needs more manpower. Again, rikki has initiated a port from akka
> -- [dakka](https://github.com/rikkimax/dakka). I think it is a right way
> to go.

Dakka is less a port of Akka and more of a complete new framework while basing it on Akka (why reinvent the wheel, after all its extremely successful).
I'm personally only using it for as an RPC mechanism, but by in large they will cover most of the bases.
I could really use some help with threading, I am sure there is something that will cause deadlocks or something much much worse. My skills in this area are quite limited.
At worse, even commenting would be a help.

> On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:
>> There's been some discussion about vibe.d recently on reddit (e.g.
>> http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443)
>> and I was wondering to what extent that's meaningful:
>>
>> "has anyone ever tied a real webservice to vibe.d? I actually tried.
>> its nowhere near complete in any sense. you simply cannot compare it
>> with go's standard http lib, sorry, I tried."
>>
>> If there's sheer work needed for completing vibe.d, I think it would
>> be great if the domain-savvy part of the community would rally around
>> it. Serving dlang.org and dconf.org off of vibe.d would be awesome
>> dogfooding.
>>
>>
>> Andrei

There is so many projects I want to work on to extend Cmsed's capabilities. From OAuth2 to PDF generation. But I can't do them (time wise). So if anybody would be interested in these sorts of projects:
* PDF creation
* Image manipulation and loading (we would need this anyway for e.g. Aurora)
* Barcode generation
* Qr code generation
* Skeleton generation (perhaps this could go into dub?)
* Something like GWT, not really possible right now nicely atleast the way I'd like it to work

Something I am very concerned about is documentation. While us in the D community are use to reading docs and at best examples. Most developers are not. They want simple examples with lots of information around it on websites, a little like how dlang's language specification is set up.

Even Vibe is pretty limited in this direction. This is also why I want a skeleton generator, Cmsed will have a complex directory setup in the future. Users shouldn't need to create that by hand.

[0] https://github.com/rikkimax/asn1
[1] https://github.com/rikkimax/Duml

On 9/07/2014 1:54 p.m., luminousone wrote:
> On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:
>> There's been some discussion about vibe.d recently on reddit (e.g.
>> http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443)
>> and I was wondering to what extent that's meaningful:
>>
>> "has anyone ever tied a real webservice to vibe.d? I actually tried.
>> its nowhere near complete in any sense. you simply cannot compare it
>> with go's standard http lib, sorry, I tried."
>>
>> If there's sheer work needed for completing vibe.d, I think it would
>> be great if the domain-savvy part of the community would rally around
>> it. Serving dlang.org and dconf.org off of vibe.d would be awesome
>> dogfooding.
>>
>>
>> Andrei
>
> There is lots of missing little bits here and their, password hashing
> functions that use crypt_(C) formated hashes.
>
> There are diet/jade template bugs still, specific major problem being
> that use of single quotes inside of double quotes when i need to pass
> strings to js functions inside of js events such as onclick inside a
> html tag, seems to be broken.
>
> There is not common database interface for sql databases(forgivable
> actually), but many of the specific database libraries are messy(ddb for
> example) and they are not any where near api "stable".

Yeah, we do need something like Hibernate, while Dvorm now is fairly stable API wise. It does abstract away pretty much everything about the database. As can be seen by having implemented POP3 and SMTP as a database provider (for EmailMessage model and only that one).

> Support for mongo is... cute?!, don't get me wrong it has a place, for
> most apps it would be fine, it is however unusable for the apps i am
> involved in.
>
> Anything supported within vibe.d itself, is great, well thought out,
> well written, clean and easy to work with. And vibe.d makes wonderful
> use of D features in a productive way. vibe.d's documentation could be
> better.

Ugh, I'd rather Vibe was split up. Honestly? right now it is slower to be compiled than Cmsed with its testing projects which I might add has quite a bit of CTFE with it.

> Having to go outside of vibe.d for anything is often gritty, and that is
> what keeps me from using it. The oddities of being required to use
> vibe.d's sockets means libraries have to be ported to the extend of
> changing that(not hard, but maintaining a changeset from the original
> authors code is cumbersome if they are not updating the lib, or if you
> would like to link it from another languages compiled code).
>
> That said if the database libraries could be brought up to snuff, one
> way or another everything else could be worked around for the most part.

On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:
> "has anyone ever tied a real webservice to vibe.d?"

Yes and see no problems with it. Looks like author has very specific expectations of "webservice" concept and can't do a thing with 100%