Hacker News Reader

Comment by rst | Hacker News Reader

If deployment is the key issue, you don't necessarily need to change the language. What you need is glue code that hooks Ruby (or Python, or whatever) into the web server at the same level as PHP hooks in, the way the ancient mod_perl does for Perl. (Which is also probably a bit less implementation work than doing a whole new language --- and also gives users the benefit of a much larger set of libraries right off the bat.)

EDIT: as pointed out below, mod_python for Apache already goes pretty far in this direction.

View on HN

> What you need is glue code that hooks Ruby (or Python, or whatever) into the web server at the same level as PHP hooks in, the way the ancient mod_perl does for Perl.

The problem with this approach is that MRI Ruby has tonnes of global state, so unless you restart the interpreter for each request, you're going to end up with state leaking between requests.

Slash is designed so that many VMs can be quickly created in the same process without any shared global state. This way each request runs in its own isolated context and can't affect any other requests.

>The problem with this approach is that MRI Ruby has tonnes of global state, so unless you restart the interpreter for each request, you're going to end up with state leaking between requests.

So what? That's how PHP works, and it's still pretty fast for most things. Would a mod_ruby be that much slower? Should still be faster than a CGI-style invocation.

PHP only works like that because Apache's default process model is process-per-request. Anything event based requires moving PHP in to multiple fcgi worker processes, and then you get limited by that.

A fast, non-shared interpreter could work very well in a threaded server, or a threaded backend to an event-based server.

Just for the record there are a huge differences between how mod_perl and mod_php work. One of the main reasons that PHP got so popular in the first place was that mod_perl was really boring and complicated to work with because it was keeping all the scripts and modules and globals loaded and shared between requests.

I second this. The language appears to be a Ruby with a slightly modified syntax, and most programmers won't be excited about keeping track of the differences. Use Ruby for this and everyone will benefit.

Sure, but doing a new language is fun, and can be a learning experience.

Reply on news.ycombinator.com