GWAN webserver allowing dynamic pages in D

[Dmitry Olshansky]

On 01-Jul-12 19:54, SomeDude wrote:
>> Use D! :) Or any other language, I see a list of supported native
>> languages in its docs.
>
> What I meant was, the author of G-WAN boasts high performance because
> his servlets are in C. But making a dynamic website in C is very both
> unproductive and very risky, security wise, so very few companies would
> do that unless for delivering static pages.

No big wonder here. But you miss important point - it's fast not because 
it's written in C. Indeed Apache, Lightty, Nginix are all written in C.
It's just (at least seems to me) that author hates C++ and uses C as  a 
native language with least amount of baggage.

  And if you use another
> language, then the performance drops and I suppose you get performance
> closer to nginx and lighthttpd (with D and C++, less than with some
> other languages).
>
Why? The main point is architecture. In the same vain I've seen some 
Java servers that run faster then C ones. Architecture & careful 
low-overhead implementation is what crucial.
For one I totally expect vibe.d to kick some serious ass in the years to 
come.

>> The fact that most production libraries (that are portable) are
>> written in C largely defeats the point of
>> "... must be absolutely bug free before being put in production, which
>> is hard with C for anything that is not trivial. "
>>
>> Also web server need NOT be absolutely bug free. It just shouldn't
>> CRASH. So memory corruption is no go, logic errors and such are
>> possible. Software always has bugs, there is no such thing as
>> "bug-free" for anything not trivial. It's just they are not important
>> or hard to trigger + "lack of feature" bugs.
>>
>
> As you say, memory corruption is a no go, so I would probably never use
> C for a serious website.
>

Right that's why static files are served as files not as a servlet per 
page. Modules of say Apache will crash it just as easy (okay one of 
Apache worker processes).
If I were to use GWAN (I'll certainly give it a try some day) then I'd 
use things like template engine and maybe doing some risky stuff in 2nd 
'mule' process. And no that != kill performance.

>> BTW PHP is a hell of a bug (not counting bugs in scripts) yet it's out
>> in the open serving most of web sites today.
>
> Yes but PHP doesn't suffer too many memory corruption bugs, so there is
> no risk of shell code injection.

Mm... the interpreter itself is bad enough. Like being not thread safe 
(is it now?). But the main problem though is bad practices that PHP 
spawned an masse. Last time I checked vulnerabilities database SQL 
injections and PHP were commonly found in the same statement/article.

-- 
Dmitry Olshansky