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
