What makes something "notable"?
gwan.com
http://gwan.com/blog/20121027.html
gwan.com
Apparently after 10 comments, the submitter renamed it to "What makes something notable?". At http://news.ycombinator.com/item?id=4113514 I read that:
"Pierre (the sole G-WAN author) says some funny things. He
also defends G-WAN using dummy accounts all over the internet
(StackOverflow, Reddit, Wikipedia, etc)."
I enjoy using gwan for my projects. So far my stack is usually nginx+gwan+mysql+mongodb.I use nginx for it's modules and it's PHP support. I use gwan to write C scripts and which is basically the original PHP scripts just converted to C for way better performance. I'v used PHP for a while now so much that I have grown to absolutely hate how slow it is. Still, PHP is easy to dev with so I keep it in my stack.
Also i did not rename the topic someone else did as stated in one of the first comments by the person who actually did the change.
That being said you are incorrect on your first point "submitter renamed it" and paranoid on your second "Coincidence?".
I usually post about gwan that being only 2 topics so far because it just so happens to be my current interest in my field of work.
These are some of the points in the documentation that give some discomfort. There are legitimate reasons to have additional flexibility and I really don't care to have language rants in otherwise objective and factual user documentation.
- Log files are set to a fixed naming convention
- Log files are rotated at midnight - it appears there is no method of adjusting this time period
- On mime-types "As this list is hard-coded you cannot add MIME types in G-WAN but we will add any type that makes sense if users ask for it."
- "How many languages do you need to learn if one of them works better than all? C made Unix, Windows, games, PDF viewers, Web browsers. C servlets will be limited by your sole imagination. C survived 40 years for a reason: it fits the task."
- "And take Javascript's optional semicolon to end statements (that was the case in some pointlessly complex parts of the JS code of the demo: a JS function defining a nested function as a parameter...). When a carriage-return replaces a semicolon then G-WAN's JS minifying (also used with HTML embedding JS) breaks the code by removing carriage-returns that 40-year-old C can safely ditch (not the more 'modern' Javascript which is far more commonly reformated to lower network latency). The mark of pure genius at work: creating problems that have no reason to exist."
edit Grammar
Bad marketing, bad licensing, crazy (ala Tesla) developer and owner being allowed to dump his brain onto the corporate site are the main problems.
When we deep dove on it, we were driven off by the site oddities and authors nonsense more than the tech (which impressed us) -- but you don't put your corporation in the hands of crazy -- even with "Source Insurance" (which is a great idea, but needs a little more explanation for US lawyers).
That said, I am reviewing it again because I am dealing with an actual CPU bound problem domain.
Based on a quick google, it does appear GWAN is massively fast at serving static files, and it does appear to be gaining traction for script-based use-cases.
I'd be interested in seeing more real-world benchmarks.
Is anybody actually using G-WAN in production?
With the success of the app store on iOS, vendors are realizing the value of eliminating the friction involved in installing native 'apps'. The sooner this happens the better, since it will mean much better software overall. Mail clients, word processors and mapping applications should not be written in javascript.
It's a damn shame that the OS vendors refuse to work together to make easily cross-platform native applications a reality. Thankfully though, if they create frictionless ways to use native code, frameworks and what not should be able to bridge the gap between OS specific API's and the hardware without performance issues. Moore's law will never make javascript word-processors good.
Javascript on the back-end just makes no sense to me whatsoever. Why not pick a programming language that was designed for the job, not something that was hacked together so it's somewhat passable at the job?
(by native i'm referring to languages traditionally used to bulid complex software, not just c/c++)
This guy obviously doesn't know node. He's comparing node.js to a dedicated webserver, when they are completely different things.
Same thing I've seen with Rebol. Freeware but closed source = no trust from users.
That said, yeah, the freeware / closed source seems to be the worst combo. But who would buy a web server they couldn't test first?
Also, the guys crazy (ala Tesla, crazy smart) personality is allowed to shine though on his site. He needs a marketing person to keep him the hell away from the customers. Make an ultra cheap or developers "trail" (no freeware), etc.
G-WAN is a freeware that can be downloaded from its web site.
How "neutral" in a debate is such kind of false claims that G-WAN can't be tested?
To me, that signals there is at least something fishy about the technology.
I'm not saying Node is bad, but I sincerely have the impression that a large majority of developers who like Node.js are mainly using it because it's 'hot technology' right now, not because it fits their technology problem so well. Event-based asynchronous servers are nice for some things, but definitely not for everything. If that were the case, Twistd and Tornado would have been much more popular before Node.js even existed. My perception is that Node.js is primarily popular because it attracted hordes of client-side developers to server programming, something that used to be too inaccessible before. Hard to dislike something that instantly gives you the impression you can write your own servers.
- Easy to install and use, especially for hordes of client side developers.
- Easy to manage packages and dependencies via npm.
- Fast and scalable for writing logic around data transportation.
Which leaves the 'JavaScript comfort zone' as the main driver of Node popularity, which while understandable, IMO isn't exactly a technological benefit, rather a downside (I don't like JavaScript, at all).
> I'm not saying Node is bad, but...
You're giving off slightly mixed messages there.
Leaving that aside, I feel that the article focuses too much on the hype words. Yes some of the hype is over the top and focuses too much on the coolness factor, yes some of the reasons given for using Node is total nonsense (e.g. what he quoted from the Wikipedia article). But none of that invalidates the valid reasons for choosing Node:
- Javascript is so much easier to program for than C/C++. This is a fact; he mentioned it several times in his article but then brushes off these claims. Writing Phusion Passenger 4's new evented architecture in C++ has been an extremely intensive effort. There's just so much you need to be aware of and take care of, Javascript would have speeded up development significantly. If course we couldn't and didn't: being system software, Phusion Passenger's core cannot rely on Javascript and must be optimized for speed.
- Javascript is fast enough for quite a lot of server software. Of course C wipes the floor with everything. If you don't mind spending 4 times longer to ship your product to market. Oh yeah, good luck recruiting that brilliant C programmer, I hope you live in a place where they are easy to come by. His bold claim that G-WAN's Javascript engine uses 2444x less resources is a bold one, but if in the end you have 2 million users and you can still handle them with 1 or 2 servers, then switching to G-WAN does not give you a lot of added advantage.
- G-WAN runs everything in-process!! Of course everything is faster then!!! It's because there's no need to perform inter-process communication and CPU synchronization, which often require (relatively slow) kernel intervention. But if one component dies, your entire web server goes down. Better hope the application programmer never makes a mistake. With Phusion Passenger we've explicitly chosen not to utilize an in-process architecture because it causes to much pain, even if it's faster.
There's also at least one logical fallacy in the article:
_"Node.js' CPU & RAM usage is so high that the scale had to be resized. The chaotic curves do not give the feeling of anything seriously engineered."_
He puts two separate scales in the same graph and then claims this? That doesn't make any sense.
Where is the source code for the benchmark? How did the benchmark look like and what's the methodology? No mention of it.
I wish the G-WAN author would focus more on the technicalities instead of trying to fight the hype. That would make the entire article much more interesting. Why is G-WAN faster? What's the difference between Node and G-WAN's Javascript engine? Etcetera. G-WAN is a very interesting product but it would have so much more potential if the author communicates in a less inflammatory and emotional way, and behaves more professionally.
> "Javascript is so much easier to program for than C"
G-WAN offers both. And 13 other languages.
> if you have 2 million users then switching to G-WAN does not give you a lot of added advantage
Node.js will never survive 2 million users if it faints at 1 thousand users.
> "Why is G-WAN faster?"
For the same reason that makes Nginx faster than Apache: better coding.
> "What's the difference between Node and G-WAN's Javascript engine?"
None. You criticize without reading. It is said that "G-WAN runs node.js as a script engine (which results in testing V8)".
> "Where is the source code for the benchmark?"
On the site that you claim that you have read.
> "G-WAN is a very interesting product but it would have so much more potential if the author behaves more professionally."
Hmmm... you probably mean, like you?
You "moderated" this Hackers News entry to:
- spread FUD about G-WAN
and
- promote Phusion Passenger (your product)
Maybe that's why you ask how G-WAN manages to be so much faster?
Correction, I am one of the Phusion Passenger authors. I do not make this a secret.
You seem to have misunderstood my response for trolling. I apologize if I came over like that, but all I want is some critical discussion and better explanations than grand claims without proof.
> G-WAN offers both. And 13 other languages.
I never said it didn't. I merely said there are legit reasons for using Javascript over C.
> Node.js will never survive 2 million users if it faints at 1 thousand users.
> For the same reason that makes Nginx faster than Apache: better coding.
Ok, now give me some details. These statements are meaningless on their own. "will never survive" contradicts real-world examples in which Node obviously did survive. Also, under what hardware? What networks? What operating systems? Under what test conditions?
Nginx is faster than Apache because of "better coding"? That vague statement doesn't mean anything. Nginx is faster than Apache partially because of its architecture: evented vs multiprocessing/multithreading, speed at the cost of flexibility, memory allocation patterns, etc. Nginx isn't anywhere near the swiss army knife that Apache is, and as soon as it is it will become comparable in performance. I can pinpoint specific areas in Nginx and explain why they're faster than the equivalent in Apache. Can you do that with G-WAN vs the rest?
I'm looking an in-depth technical study of what makes G-WAN faster than the competition, not vague grand statements.
> On the site that you claim that you have read.
They have the source code for the benchmarking app but not the hello world app. Direct link please.
> You "moderated" this Hackers News entry to: > - spread FUD about G-WAN
Calm down, this isn't a war. I apologize if it come over as FUD, but it was merely critical curiosity.
> and > - promote Phusion Passenger (your product)
Correct. I make no attempt to hide this. In fact, I challenge you to find any promotional messages that are not based on facts. I do not, and do not want to, promote my products with FUD or inaccuracies.
> Phusion Passenger is not censored on Wikipedia because, like Node.js, it is much slower than G-WAN.
What do censoring and Wikipedia have to do with this? And correct, it is slower. We focus on ease of use, reliability, stability and features, not raw performance. If highest req/sec at the cost of everything else is what you want, then you are looking at the wrong product.
I cannot help but feel that your statement that Phusion Passenger is "much slower" than G-WAN is an attack in an attempt to defend G-WAN. Again, it is not my intention to troll or spread FUD on G-WAN.
> Maybe that's why you ask how G-WAN manages to be so much faster?
Yes, that is exactly why. As an application server author I am constantly seeking to improve my knowledge and skills in this area.
Performance is not always the end goal. It comes at a cost. Nginx is not faster than Apache because it's "better coded" but because of tradeoffs in architecture and features. Likewise, there are ways to make Phusion Passenger faster, but they come at the cost of reduced code maintainability, reduced feature set, etc.
And uhm, klue, whoever you are... please don't reply from a newly created account made for the mere sake of replying to me. I want a civilized, technical discussion, not a pissing contest. Please reply with your real account.
A year ago, a member of the former G-WAN community wrote a handler and V8 wrapper: https://gist.github.com/1077769. Guess that the G-WAN author (Pierre) tweaked that a little bit more.
Tested it myself. For simple "hello world" it was 5.5x faster than node. Quite impressive given the fact that a new V8 context is created with every request. But, again, no batteries included.
vert.x used the JavaScript bindings via Mozilla Rhino. I guess that a pure Java test could be a little bit faster than that.
#include "gwan.h" // G-WAN exported functions
int count=0;
int main(int argc, char *argv[])
{
if (!count) printf("New Counter!\n");
xbuf_xcat(get_reply(argv), "Hello World %d",count++);
return 200; // return an HTTP code (200:'OK')
}So was the benchmark the author posted with microcaching turned on? While it's a legit way to reduce the load in real-world situations, it feels a little like cheating when used in a benchmark.