5 ms·

> Even supposing the claims are true, currently it's very limited in what languages it supports. It's great at static content, but dynamic content must be writt

by ers35 14y ago

> Even supposing the claims are true, currently it's very limited in what languages it supports. It's great at static content, but dynamic content must be written in C or use a C library. That is no longer accurate. G-WAN now supports C, Java, C++, D, and Objective C out of the box. [1] I am the someone who is implementing FastCGI support. [1]http://gwan.ch/developers http://gwan.ch/developers

eropple 14y ago
I'm not trying to be disrespectful because I'm sure you've put in a lot of work on your part of the project, but little to nothing on that page makes any sort of sense. Where is this terrifying efficiency hit from "the frenetic wave of abstraction layers" that the author of that page is claiming? Does the author even realize that he sounds like a huckster and his claims about other projects have only a tenuous relationship to reality? And why would I trust the judgment of developers who think that writing web applications in C is a perfectly cromulent idea? Second reaction: am I actually supposed to take seriously something that looks like that Java sample? 'Cause, er, I know a teeeeeensy bit about Java, and my first reaction was "what kind of moron would write Java like that?". Java isn't C, and this guy's bizarre worship of "programming to the metal" (it's a web architecture for god's sake!) makes no sense there.
- deleted 14y ago
  [deleted]
- cdcarter 14y ago
  From my preliminary read of that page and the linked loan.java, it looks like the java is actually being processed into C code and then complied by the server. Can anyone confirm if this is how the system is architected to "support" java?
  - eropple 14y ago
    It's honestly hard to tell, because behind the SEO-dross and random attacks on established, already-high-performance tools, there aren't many details at all. At first (I hadn't looked at the linked file) I immediately said "you have to be kidding me", but...then I looked at the Java file and I think you might be more on-target than I'm comfortable with. It does not look like it's running in a normal JRE, which makes me really skeptical of the sibling post claiming that "you can write Java however you want". (If it was running in a normal JRE, a ton of the stuff in loan.java makes little sense...)
  - chc 14y ago
    The FAQ says it depends on either OpenJDK or the official Oracle Java, so it doesn't sound like it's a special Java-to-C compiler, unless it's something like a runtime JVM bytecode-to-C compiler.
    - eropple 14y ago
      That could be the case--I'm not going to dig deeply into it because honestly I like having my brain still work, but it could be that the insanity in loan.java is just because of the crappy C API being wedged into Java. I'm not exactly sure how his claims of instant refreshing "scripts" works if it's a conventional JDK, though. I mean, that's just not possible, even with hot reloading (as Play Framework developers have learned to their disappointment).
    - asharp 14y ago
      It wouldn't surprise me if it has something like GCJ creating something like a .so that it loads on the fly. That is just a thought though, i haven't inspected it particularly closely.
- 1337p337 14y ago
  Based on the graphs, the contents, and the over-the-top design, I was wondering if this was a joke or something until seeing this thread. So I'd agree that alarm bells may be warranted. On the other hand, I have written a few web applications in C. It's not that bad! :) The nice thing about it is that if you link statically, write CGI programs, and ignore memory management (or, rather, malloc all you care to and delegate garbage collection to the OS when your process goes away), you can get something that runs quickly with minimal hassle on a small device. I don't recommend it unless you have some bizarre constraints, but it's really not that bad! That approach doesn't seem possible with this server, sadly.
  - eropple 14y ago
    Sure, you can do it, but CGI is pretty much dead as a "fire up a process, do something" method of serving web content. If the request processor isn't also your HTTP server, you'd generally start up a FCGI daemon that handles requests. At that point the amount I trust 99.9% of C and C++ programmers to not screw the pooch (between dealing with HTTP requests, database interaction, string templating...) trends very close to zero. What you describe might be workable in the small, but at that point you might as well fling up Apache and mod_php. It'll probably be faster.
    - 1337p337 14y ago
      If CGI is dead, I had not noticed. :) I'll admit that I don't write CGI programs often, but I do still write them. I think, though, that the database interacting, templating, etc., are things that you will very nearly always do in PHP because they're there. File-backed storage (if any storage is even needed) is more than adequate for most cases where one might write a CGI program in C. The last time I had occasion to write something from scratch and target CGI, I was generating graphs. No templating, no database, very fast. The major pain of templating lies in C's string handling, though, and if you aren't worrying about freeing memory, there's not much pain. As far as HTTP goes, if the protocol was designed to be parsed in C, it's not often difficult to parse in C. But for all of those things, there's a library. I can't comment specifically about whether or not mod_php would be faster (since I used PHP only briefly and several years ago) but I suspect very strongly that the overhead of firing up a small, statically linked C program beats it. As I said previously, I don't think it's usually a good idea, but it's a more than viable tool and nice to keep in the box.
Osiris 14y ago
I did note in the comment about PHP support. I did notice the website mentioned C++/ObjC, but I just lumped those in as C variants. The Java integration looks interesting. The author in a forum post did say that he doesn't think that FCGI is the right way to go and suggested asking Zend to build a C library for GWAN that could run PHP code [1]. I find that unlikely unless GWAN really starts getting a large following. [1] http://forum.gwan.com/index.php?p=/discussion/comment/3801/#Comment_3801 http://forum.gwan.com/index.php?p=/discussion/comment/3801/#...
- ers35 14y ago
  PHP support is important for backwards compatibility. This is one reason why I am implementing FastCGI. See [1] for reasons why PHP+FastCGI is a poor choice in 2012. [1]http://gwan.ch/en_fastcgi.html http://gwan.ch/en_fastcgi.html
otoburb 14y ago
Actually, on the developers page you linked it also lists JS, Lua, Go and Python as languages for GWAN handlers. I assume that means that those languages are supported via separate processes that are called out by the GWAN process since the page breaks those languages out separately from 'natively' supported C/C++/Obj-C, D and Java.
- ers35 14y ago
  I wrote the Lua, Go, and Python examples handlers. JavaScript, Lua, and Python can be linked directly with the server for performance you would not get via separate processes. I had more difficulty with Go, which you can read about on the forum.[1] They all work, but are just proofs of concept at the moment. G-WAN makes it easy to link with any C library, so it is not hard to use languages that expose a C API such as those listed. It is just a matter of writing a more complete handler. [1]http://forum.gwan.com/index.php?p=/discussion/463/writing-g-wan-servlets-in-go/#Item_2 http://forum.gwan.com/index.php?p=/discussion/463/writing-g-...

by ers35 14y ago

eropple 14y ago

I'm not trying to be disrespectful because I'm sure you've put in a lot of work on your part of the project, but little to nothing on that page makes any sort of sense. Where is this terrifying efficiency hit from "the frenetic wave of abstraction layers" that the author of that page is claiming? Does the author even realize that he sounds like a huckster and his claims about other projects have only a tenuous relationship to reality? And why would I trust the judgment of developers who think that writing web applications in C is a perfectly cromulent idea? Second reaction: am I actually supposed to take seriously something that looks like that Java sample? 'Cause, er, I know a teeeeeensy bit about Java, and my first reaction was "what kind of moron would write Java like that?". Java isn't C, and this guy's bizarre worship of "programming to the metal" (it's a web architecture for god's sake!) makes no sense there.

deleted 14y ago
[deleted]
cdcarter 14y ago
From my preliminary read of that page and the linked loan.java, it looks like the java is actually being processed into C code and then complied by the server. Can anyone confirm if this is how the system is architected to "support" java?
- eropple 14y ago
  It's honestly hard to tell, because behind the SEO-dross and random attacks on established, already-high-performance tools, there aren't many details at all. At first (I hadn't looked at the linked file) I immediately said "you have to be kidding me", but...then I looked at the Java file and I think you might be more on-target than I'm comfortable with. It does not look like it's running in a normal JRE, which makes me really skeptical of the sibling post claiming that "you can write Java however you want". (If it was running in a normal JRE, a ton of the stuff in loan.java makes little sense...)
- chc 14y ago
  The FAQ says it depends on either OpenJDK or the official Oracle Java, so it doesn't sound like it's a special Java-to-C compiler, unless it's something like a runtime JVM bytecode-to-C compiler.
  - eropple 14y ago
    That could be the case--I'm not going to dig deeply into it because honestly I like having my brain still work, but it could be that the insanity in loan.java is just because of the crappy C API being wedged into Java. I'm not exactly sure how his claims of instant refreshing "scripts" works if it's a conventional JDK, though. I mean, that's just not possible, even with hot reloading (as Play Framework developers have learned to their disappointment).
  - asharp 14y ago
    It wouldn't surprise me if it has something like GCJ creating something like a .so that it loads on the fly. That is just a thought though, i haven't inspected it particularly closely.
1337p337 14y ago
Based on the graphs, the contents, and the over-the-top design, I was wondering if this was a joke or something until seeing this thread. So I'd agree that alarm bells may be warranted. On the other hand, I have written a few web applications in C. It's not that bad! :) The nice thing about it is that if you link statically, write CGI programs, and ignore memory management (or, rather, malloc all you care to and delegate garbage collection to the OS when your process goes away), you can get something that runs quickly with minimal hassle on a small device. I don't recommend it unless you have some bizarre constraints, but it's really not that bad! That approach doesn't seem possible with this server, sadly.
- eropple 14y ago
  Sure, you can do it, but CGI is pretty much dead as a "fire up a process, do something" method of serving web content. If the request processor isn't also your HTTP server, you'd generally start up a FCGI daemon that handles requests. At that point the amount I trust 99.9% of C and C++ programmers to not screw the pooch (between dealing with HTTP requests, database interaction, string templating...) trends very close to zero. What you describe might be workable in the small, but at that point you might as well fling up Apache and mod_php. It'll probably be faster.
  - 1337p337 14y ago
    If CGI is dead, I had not noticed. :) I'll admit that I don't write CGI programs often, but I do still write them. I think, though, that the database interacting, templating, etc., are things that you will very nearly always do in PHP because they're there. File-backed storage (if any storage is even needed) is more than adequate for most cases where one might write a CGI program in C. The last time I had occasion to write something from scratch and target CGI, I was generating graphs. No templating, no database, very fast. The major pain of templating lies in C's string handling, though, and if you aren't worrying about freeing memory, there's not much pain. As far as HTTP goes, if the protocol was designed to be parsed in C, it's not often difficult to parse in C. But for all of those things, there's a library. I can't comment specifically about whether or not mod_php would be faster (since I used PHP only briefly and several years ago) but I suspect very strongly that the overhead of firing up a small, statically linked C program beats it. As I said previously, I don't think it's usually a good idea, but it's a more than viable tool and nice to keep in the box.

Osiris 14y ago

I did note in the comment about PHP support. I did notice the website mentioned C++/ObjC, but I just lumped those in as C variants. The Java integration looks interesting. The author in a forum post did say that he doesn't think that FCGI is the right way to go and suggested asking Zend to build a C library for GWAN that could run PHP code [1]. I find that unlikely unless GWAN really starts getting a large following. [1] http://forum.gwan.com/index.php?p=/discussion/comment/3801/#Comment_3801 http://forum.gwan.com/index.php?p=/discussion/comment/3801/#...

ers35 14y ago
PHP support is important for backwards compatibility. This is one reason why I am implementing FastCGI. See [1] for reasons why PHP+FastCGI is a poor choice in 2012. [1]http://gwan.ch/en_fastcgi.html http://gwan.ch/en_fastcgi.html

otoburb 14y ago

Actually, on the developers page you linked it also lists JS, Lua, Go and Python as languages for GWAN handlers. I assume that means that those languages are supported via separate processes that are called out by the GWAN process since the page breaks those languages out separately from 'natively' supported C/C++/Obj-C, D and Java.

ers35 14y ago
I wrote the Lua, Go, and Python examples handlers. JavaScript, Lua, and Python can be linked directly with the server for performance you would not get via separate processes. I had more difficulty with Go, which you can read about on the forum.[1] They all work, but are just proofs of concept at the moment. G-WAN makes it easy to link with any C library, so it is not hard to use languages that expose a C API such as those listed. It is just a matter of writing a more complete handler. [1]http://forum.gwan.com/index.php?p=/discussion/463/writing-g-wan-servlets-in-go/#Item_2 http://forum.gwan.com/index.php?p=/discussion/463/writing-g-...