What makes something "notable"?(gwan.com)
gwan.com
What makes something "notable"?
http://gwan.com/blog/20121027.html
http://gwan.com/blog/20121027.html
18 comments
This submission was originally called "Node.js is all just hype"!
Apparently after 10 comments, the submitter renamed it to "What makes something notable?". At http://news.ycombinator.com/item?id=4113514 I read that:
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 just found the gwan topic interesting and the blog posts even more so.
To eliminate any sort of crazy conspiracy theories, I am in no way shape and or form associated with gwan,nginx,msql,mongodb ect ect.
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.
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.
If what you're saying is legit then I encourage you to continue doing what you've been doing. I too am interested in G-WAN, but I just wish the documentation and articles have more technical substance, and I wish someone with a long, good track record can comment on it.
There are various 'tells' in the user documentation that indicates a lack of flexibility in the product and its authors. That aside, it is a very fast server and if you write your servlets in C, those too will be quite speedy.
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."
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."
They really should make this open source and switch to community model of development.
Same thing I've seen with Rebol. Freeware but closed source = no trust from users.
Same thing I've seen with Rebol. Freeware but closed source = no trust from users.
It is kinda sad. The performance of his stack is second to none (in my testing he undersells it). I really do like configuration via directory structure, and it has various cool tooling in it.
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.
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.
> "who would buy a web server they couldn't test first?"
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?
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?
Klue, calm down. The website's navigation isn't exactly the most intuitive. I can imagine that to a lot of people it isn't immediately obvious that they can download and use it for free.
I modded this submission up not because I agree with it but because I want a discussion. The G-WAN author has been known being... confident. He claims to be faster and more scalable than Nginx by a significant factor. He attributes the speed partially to the fact that his code contains few branches, where he defines even function calls as branches. Both statements are bold claims, and I can only imagine how it would take a genius to maintain "branchless" code like that.
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.
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.
@FooBarWidget, an obvious Phusion Passenger troll (look at his posts)
> "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:
Maybe that's why you ask how G-WAN manages to be so much faster?
> "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?
> @FooBarWidget, an obvious Phusion Passenger troll (look at his posts)
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.
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.
There's no "G-WAN's Javascript engine". Just plain old V8 embedded via a handler. You get just the basics, no batteries included aka you need to code the bindings to various things (like FS, crypto, etc) by yourself.
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.
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.
That makes me all the more curious: why is it faster? I cannot imagine Node doing something obviously wrong that would explain the difference. Evented I/O is pretty well understood, I/O loops aren't that hard and it's all just accept()/read()/write()/close() at the end of the day. Where does the 5x difference come from?
It is plausible though. node.js have its fair share of "slowness" when compared to other async frameworks for the basic "Hello World" (shameless plug): http://www.saltwaterc.eu/async-frameworks-hello-world-showdo...
vert.x used the JavaScript bindings via Mozilla Rhino. I guess that a pure Java test could be a little bit faster than that.
vert.x used the JavaScript bindings via Mozilla Rhino. I guess that a pure Java test could be a little bit faster than that.
Because it caches (http://gwan.com/faq#cache) response under high concurrencies. Try to benchmark this code:
#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')
}Wow, I didn't know that. I certainly did not expect to find that information in the FAQ. In fact this is the first time I've heard of a web server doing that.
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.
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.
I wrote my feelings here: http://www.codingnot.es/why-i-ll-never-trust-g-wan/
I hear this a lot. Node.js seems to have gained quite a bit of popularity though, I see developers swear by it like a religion regularly.
> I see developers swear by it like a religion regularly.
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.
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.
Node is not everything to everyone, but for a lot of people, it's the right technology at the right time.
- 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.
- 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.
I would say Python frameworks like Flask or Pyramid offer the first 2 benefits as well, and when used properly in combination with a caching proxy and container server that allows asynchronous processing the 3rd benefit too. So they are not unique to Node.js although out-of-the-box, as a standalone application server, Node will be faster.
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).
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).
> To me, that signals there is at least something fishy about the technology.
> I'm not saying Node is bad, but...
You're giving off slightly mixed messages there.
> I'm not saying Node is bad, but...
You're giving off slightly mixed messages there.
how is this website so ugly?
Lol, nice try at a bit of self-promotion there.
This guy obviously doesn't know node. He's comparing node.js to a dedicated webserver, when they are completely different things.
This guy obviously doesn't know node. He's comparing node.js to a dedicated webserver, when they are completely different things.
Agreed - the article content is misleading at best..and some of the other comments on this thread smell like astroturf.
Like others I couldn't get beyond the formatting - the website looked like it was shouting at me. Hard to take something seriously when it's displayed like a ransom note.
tl;dr: Guy is angry at Wikipedia because his web server doesn't meet Wikipedia's "notability" requirements while Node.js does. Ah, also his server is faster than Node.js. Here's a HN comment thread about G-WAN: http://news.ycombinator.com/item?id=4113514
I've seen some comments/postings to HN about g-wan, and I still can't work out if it's some really elaborate troll or not. Has anyone played with it? I can't imagine that this very strange license section in the FAQ: http://gwan.ch/faq#license, is going to help people want to try it!
edit Grammar
edit Grammar
It isn't a troll, the performance numbers are real and it is a fairly slick product.
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.
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.
The formatting and the delivery on that site are confusing; both feel somewhat aggressive. It could just be a chinese / cultural / marketing thing we're not used to, or maybe the author's a little too confident.
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.
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.
The guy is from Switzerland: http://gwan.ch/about
Is anybody actually using G-WAN in production?
Is anybody actually using G-WAN in production?
The aggressive tone is off-putting, the formatting is distracting and the target of criticism seems to be Wikipedia, as well as Node. Talk about concurrency.
Managed to get throught the odd formatting, and I don't think the article's worth it.
That's too bad, 'cause the idea looked interesting: it's true that parts of developers' community are subject to the "go onto hype" phenomenon, and I'd have read with pleasure a serious analysis of that, which could open a constructive debate.
But here it's only a big rant mixed with conspiracy theory, about "why does everybody speaks about anything but g-wan", made up by somebody who obviously wants to get some buzz for his product.
I see most new developments in web technologies as layers upon layers of frameworks designed to make it easier to create ever more complex web-based applications that will ultimately become irrelevant when people realize that the complexity and the scaling requirements of the applications being created are much better served by normal non-web focused programming languages.
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++)
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 blog is really hard to read. What's with all the colored rectangles around the words. Tiring...
I got a strong time cube vibe from that site.
[deleted]