ITT YOU MAKE THE CLAIM RUBY CAN DO EVERYTHING

BECAUSE YOU CAN ALWAYS CALL C CODE TO DO IT RIGHT. AM I RITE?

I AM

Lisp is for dummies.

6502 assembly is 6502 assembly for smart people

Word if for writing words and shit

Stop complaining about other people's languages and just WRITE THE DAMN CODE

Lisp is Speech for dummies

Has Ruby for webhosting even been real-world tested on large high-traffic websites?

I know that Perl and PHP have.  Perl runs high-traffic sights such as slashdot.org and livejournal.com.  I know that digg.com had it's scaling problems with MySQL moreso than PHP.  Are there any real-world examples of large high-volume sites like these that run on Ruby (doesn't have to be Ruby on Rails)?  Preferably sites that aren't mostly cached/static pages (dynamically updated content that is always being updated).

Has Ruby for webhosting even been real-world tested on large high-traffic websites?

Apparently PennyArcade now uses Ruby on Rails. Not exactly a ringing endorsement, mind.

Preferably sites that aren't mostly cached/static pages

If you aren't an idiot, you'll be caching as much as possible, no matter what the language. Static pages are even better. This is one particular pet peeve I have about a lot of PHP "programmers".

Yea.  I know that you want to cache as much as possible.  But with sites like digg.com the content is changing so rapidly that it's not like caching it will do too much since there will probably be an update in the next minute or two.   And even on top of that, you can get RSS feeds for a particular search of the news items.  I'm not sure how they implement that behind the scenes, but a lot of these stuff is dynamically created.  Sure it's cached or static to some degree, but by questioning was more along the lines of Ruby being able to handle sites where there is lots of content that has to be dynamically created rather than stored in a static/cached page.  I'm just trying to get a feel for how well Ruby would handle being under a heavy load of actual script executions, rather than just serving up pre-packaged pages.

I mean blogs are easy.  You can generate all of the blog pages statically if you want to (probably the best way), and just update them when you post new content.  But let's face it, most people's blogs won't get enough traffic for that to be of any consequence anyways.  Most people's blogs could handle being 100% dynamic for the 2 hits a week that they get.

>>1
RUBY CAN PRINT MONEY!!!

Kawaii de gozaru.

it's not like caching it will do too much since there will probably be an update in the next minute or two.

I disagree. Considering the type of traffic that digg.com must be getting, caching would hugely benefit it. The overhead of a dynamic page is so high that all it takes is two hits instead of one to make caching a win. And you can bet digg serves more than two pages between updates.

Now, I've never used Ruby to serve webpages, but if you use FastCGI and a dose of static HTML, I'd be very surprised if you couldn't make a heavily-loaded site, unless it's something like Amazon's shopping carts.  I'll also point out that Ruby and PHP are comparable for speed; if you want a popular fast scripting language, you should be looking at Python or Perl.

>>51

I realize that caching still would help out a lot.  I just phrased that poorly.  What I meant is that the scripting engine is still racking up CPU cycles (from the sheer amount of updates, so the efficiency of the engine and its performance are being put to the test.  It's not like a page that is updated infrequently or just weekly where static pages/cached pages basically make it so that the script is rarely hitting up the CPU and it's mostly just disk reads.

What is the difference between CGI/FastCGI?  I've only ever used PHP through mod_perl for serving up web pages.  While I'm at it, what is the difference between running a script through CGI verses a language specific module (e.g. mod_perl, mod_python, mod_php, etc)?  I understand that to some extent it's supposed to be optimized, but in what way and to what extent?

To oversimplify things a bit, mod_perl/php/python eliminate the overhead of loading and forking a new process each time a request is made. Relative to what the process itself does, this overhead is usually gigantic.

FastCGI does the same thing, except instead of embedding an interpreter in the httpd daemon, it spawns a seperate persistent process that doesn't terminate. The same process sits there, accepting requests and returning data.

Performance-wise, there isn't a big difference between mod_* and FastCGI, but a FastCGI process won't affect the stability of the httpd daemon (particularly useful if you're not using the MPM prefork), and it scales better (distribute processes across multiple machines). The downside is that things like mod_perl give you incredible access to Apache's innards.

I forgot to mention: CGI treats your script like a normal external program, so you end up spawning a new process everytime someone hits a URL that references said program. This is horribly slow.

>>53

Does that mean that each httpd gets its own persistent interpreter process?  Or is there one for all httpd processes.  If there is one for all processes, then doesn't that add wait time as the a request coming in while another request is being processed will have to wait.  Or does the persistent interpreter process spawn it's own threads/child processes?

For the mod_*, it's embedded in the daemon, so there's one instance per httpd process. Of course, with a modern VM and copy-on-write, that's not such a big deal.

For FastCGI, it's a bit more complicated. The way it's normally used, you can have any number of httpd processes talking to any number of FastCGI processes. You can have one or several httpd process(es) talking to one or several FastCGI process(es). If there aren't enough FastCGI processes to fulfill demand, more are spawned, and if the demand is low, excess processes expire.

Ruby can make pigs fly!

今時ギャルのエッチなエッチなお仕事
 すごいの(*゜∀゜)=3!!キタコレ!
巨乳娘と息子がご対面。
挨拶そこそこでローションパイズリいただきました！

着やせギャルを脱がす醍醐味！これほど興奮するものはない。
服をめくると形のいいオパイがブラの中に収まりきれずに
乳リンはみ出してる！
だからブラジャーも脱がすとボヨヨンと出てくる超美巨乳。
もうこなったら揉んで挟んで舐めまくりhttp://www.city689.com/mutou/wp.scr

PROTIP: If you read Ruby, you can write Japanese

>>60
WRYYYYYYYYYYYYYY

wtf is going on with shiichan :|

my guess is >>60 was deleted by a moderator

>>63
I-impossible!?  How could they possibly be that powerful!?  I WONT FORGIVE THEM@!!!!!!!!

CALL C C????

>>62-64
Probably just PHP glitches.

>>66
There are no glitches in PHP.

>>67
Yeah, they're features.

Lisp is Fortran for dummies

Lisp is for dummies
Read K&R

RUBY DID WTC!!!
LOL RUBY!

Ruby can do anything except be not retarded.

http://www.djangoproject.com/snakesandrubies/

>>1
Can it calculate love, though?

irb(main):010:0> Object.send(:what?, :love)
=> "Baby don't hurt me"

　 ∧＿∧　　　∧＿∧　　　∧＿∧　　 ∧＿∧　 　 　　∧＿∧
　（　・∀・） 　 （　｀ー´）　　（　´∀｀）　 （　ﾟ ∀ﾟ ）　　　 （　＾∀＾）
　（　　　　つ┳∪━━∪━∪━━∪━∪━∪━┳⊂　 　 　つ
　｜ ｜　|　 ┃This thread has peacefully ended.┃　｜ ｜ ｜
　（_＿）＿） ┻━━━━━━━━━━━━━━┻　（_＿）＿）　　　　　Thank you.

>>76
（￣へ￣）

. ∧＿∧
　（　＾∀＾）
　（　　　 ）
　｜ ｜つ|
　（_＿）＿）

haha just like haskel it can call c code too.

I think this is related:

My good friend had just begun his stint as a JET. He had been in Japan for only two weeks when he was introduced to all the teachers at the school in which he was to begin teaching. In front of the teachers he was asked by the principal one of the standard questions gaijin are asked - "Can you eat Japanese food?"

"Oh yes, it is oishii!" he replied.

"And what is your favourite Japanese food?" the principal asked.

A small amount of mental turmoil set in. What was the name for that sweet red bean paste that he had been eating for the last two weeks? Something sounding like manju or anko? Unable to quite remember, his brain made the terrible decision to combine those two innocent foodstuffs.

"Manko," he said.