critique of vibe.d

[Rikki Cattermole via Digitalmars-d]

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.