Slashdot Mirror
G-WAN, Another Free Web Server
mssmss writes "Has anyone used G-WAN — a free (as in beer), supposedly fast and scalable Web server? The downside is it supports only C scripts, which the author claims is a plus since most programmers know C anyway. There is currently only a Windows release and no clear answer in their FAQs whether there would be Linux/Solaris releases. As an interesting aside, releasing a Web server while at the same time fighting a losing battle (PDF) with a large bank over a piracy claim of $200 million (the bank is alleged to have done the piracy) is quite a feat."
Where's the value/point in releasing another limited-utility webserver?
I see the point in having a few options for a particular category, so that you can choose between different optimizations for things like cost, performance, and compatibility. But why something of limited utility (only runs C scripts) compatibility (only runs on 'doze) AND cost? (not OSS, but it's free!)
I don't know. Even with a fairly "heavy" web server such as Apache, the performance increases by going with another "lighter" platform seldom represent more than a year or so of hardware advance.
So.... Why?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
It looks like this chap has a grudge against Microsoft (he says his company was "eradicated from the market the usual way", apparently by Microsoft) so he wrote this webserver to hit them "where it hurts".
I don't know if spite is the best motivation to write excellent software.
If you're a zombie and you know it, bite your friend!
Speed and security. The endless permutations and add-ons to Apache do, in fact, cause a significant security and compatibility and performance burden, much as the endless and often poorly written add-ons to Perl create similar issues. The idea can be taken to extremes, but how many of todays Perl and PHP website scripting security issues would evaporate if the authors were forced to write in a less flexible language that took a few moments to actually compile before being enabled?
People claim Apache is slow, but why not using a reverse proxy like Varnish to "speed it up" and still keep the features. I really see no reason why I should use G-WAN or lighttpd.
Not everybody is serving easily-cacheable stuff. Reverse proxies are great for semi-static websites like news sites, but they are useless for social-networking, webmail and other interactive sites that need to render customized content for each particular user.
Anyway, nginx is my current favorite web server.
...could be worse - it could've used only the .NET framework
Oh, wait...
Quo usque tandem abutere, Nimbus, patientia nostra?
Scripting languages tend to be written in C. I've written my share of HTTP app servers as native code and some in scripting languages (one in C/lua a few years back -- fast). Frankly, the typical web stack is a rickety, cobbled together piece of shit! Web server, rewrite engine, scripting host, language framework, database abstraction library over an underlying database lib... It's often cleaner and leaner to write the entire app as a daemon which handles a subset of HTTP and then to reverse proxy.
I've been playing with Google's go language recently; even given it's current state, I'll not hesitate to state my preference for go over any scripting language for a web app.
C scripts are not C, it's just a scripting language that looks like C. You can't actually import normal C libraries and if I recall (I've only used C scripts once) you can't do much in terms of memory operations. On top of that they are scripts, so if they screw up the parser will tell you where thing crashed. Please don't be so critical of something you don't understand, scripts with C like context are nothing new and there are a variety of advantages to using the same syntax between your actual code and your scripting language.
Also, the scripting languages you mentioned are either not easily embeddable or somewhat focused for certain purposes. You should realize simple scripting and embedded scripting can be very different things. Particularly scripting languages like Lua can prove to be quite incredible, offering extremely advanced features (like tables) while still remaining surprisingly quick. Depending on what you are doing Lua can actually allow less capable programmers to write surprisingly complex code to enhance your program - we used it about a half year ago and with our scripts you could get moving objects on the screen in 3 lines, interactivity in 7, and easily an entire interface in less than 100. There are also a variety of scripting languages for actual embedded (as in hardware) applications which focus on being fast and light, but are often equally light on advanced features. I'd like to see you get python running capably on an 8-bit MicroController, or php doing something useful on one....
Absolutely. What makes me especially excited about trying G-WAN is that whenever it crashes I'll have the extra fun of figuring out whether the reason it crashed was because my own C code crashed, or because the code in his web server crashed.
Finding where a program crashed is way easier than finding a logic error, and those can occur in any language. Actually, debugging crashes can lead to discovery of certain kinds of logic and/or runtime errors that would be difficult to find if your runtime environment is protecting you from ever seeing a crash (heaven forbid).
I'm as much a fan of high-level languages, nice runtime environments, and useful abstractions as anyone, but I also happen to think that C gets more flak than it deserves. I really think universities are doing their graduates a disservice by educating them in the safe, comfortable confines of Java if they don't also teach them C. In my own subjective experience, the most capable and successful programmers I know (in any environment) are also the ones who are very comfortable in environments without garbage collection and restricted memory access.
This author takes full ownership and responsibility for the unpopular opinions outlined above.