Where will D sit in the web service space?

ChangLong via Digitalmars-d digitalmars-d at puremagic.com
Mon Jul 13 05:12:20 PDT 2015


On Monday, 13 July 2015 at 10:49:16 UTC, Sönke Ludwig wrote:
> Am 13.07.2015 um 06:29 schrieb ChangLong:
>> I has use vibe.d for a small project recently,  after finish 
>> that I
>> think the follow fact will
>> prevent many programmers use vibe.d in commercial projects:
>>
>> 1) Lack of successful open source project for real product
> I don't know of any big front-end product, but it's used for a 
> variety of smaller building blocks. Probably it would be a good 
> idea to start collecting projects using vibe.d on a sub-page on 
> vibed.org to get some mutual marketing boost.
>
>> 2) Multi thread performance is poor, scalability is not suit 
>> for big
>> project
> My guess is that this was caused by the GC. In the benchmarks I 
> did, it scaled up more or less perfectly, but I was careful to 
> not perform any per-request GC allocations there.
>
> Using multi-process scaling may be a viable alternative if your 
> project relies on the GC. Or, if the project partially performs 
> CPU intensive computations, it may make sense to offload only 
> those computations to worker thread, relying purely on async 
> I/O concurrency in the main thread for network scaling.

Thanks for the tips, for current I run a single thread vibe.d 
application with 20~80% CPU usage, the GC is the major problem 
for me.  I try parse httpclient result and save it in sqlite with 
like 32 task running concurrent.  Before I wrote a similar 
project using nodejs, performance is better

>> 3) No Inversion of Control (aka: Dependency Injection) Concept
> Since this is a broad term, on which level do you miss an 
> explicit concept for this? Any concrete example?

Like this: 
http://symfony.com/doc/current/book/service_container.html
It is easy to expand services and maintains application with many 
components
And it is also very good for business logic decoupling

>> 4) No mature ORM/ODM components
> This can indeed be an issue. But, even if this isn't a full 
> ORM, at least the MongoDB and Redis drivers in vibe.d support 
> direct mapping to D types using the serialization module.

I has read MongoDB but not use it yet, thank for the tips.

>> 5) No Form/Validator/Translation/Locale Components
> See vibe.web.web: http://vibed.org/docs#web-interface-generator
Seems the Translation and Locale is include:)  for Validator/Form 
it can be integration with ORM/ODM module.

> There are still missing bits, but a lot is already there. 
> Please let me know of anything particularly useful that is 
> missing.
>
>> 6) No modernize framework
> I've not heard of that term. Can you explain?
I am sorry for my poor english.   I mean like expressjs/sailsjs 
for nodejs,  rails for ruby, symfony/laravel for php.

With a good framework the code is more easier to maintain,  
faster development process, more easier to find and fix bug.  All 
in all, with higher productivity

I know that in practice there are many negative examples of 
excessive dependence on the framework, but IMHO that only prove 
that the developers is not good programmer.

Vibe.d is great progress D has made in web development field. But 
compared to other languages disadvantages are also obvious: The 
use of the small number of small contributors, less community 
members, lake of success example ....



More information about the Digitalmars-d mailing list