Mono, gcj, java, c++, what?

[markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org (Mark Woodward)]

On 08/28/2010 05:14 PM, Dan Ritter wrote:
> On Sat, Aug 28, 2010 at 06:53:21AM -0400, Mark Woodward wrote:
>    
>> OK, how about a little thought experiment, say you want to write a
>> server based back-end system these days.
>>      
>
> Write the part that deals with the web frontend in Ruby on Rails or
> whatever interpreted, fast-development language you are comfortable
> with.
I wouldn't recommend Ruby, maybe it has changed significantly in the 
last year or so, but its "green threads" design is very problematic in a 
programming sense when communicating blocking I/O. All blocking calls 
have to be asynchronous for other threads to run while one waits.  So, 
you have and effective "heavy" one thread per process model.

We eventually had to create a "mongrel cluster" fronted by nginx to load 
balance across multiple single thread ruby processes. On top of that, 
ruby is slow. Very slow. So slow as to make molasses seem like mercury.

PHP is slow, but not that slow, and it has the advantage of working off 
the back of apache with real threads. I'd use PHP over Ruby.
> You must be able to run this on many machines with a load balancer.
>    
These days? You'd be surprised at the capacity of $600 worth of computer 
supplies. Its enough to run all but the very big sites.
> Write the part that does interesting (hard, fast) stuff in C or C++.
>    
This is a very good model, indeed.
> If you need a different language for that, you already have a really good
> reason, don't you? That part needs to be able to do its thing in parallel
> on many independent machines, load balanced or otherwise.  Deal with
> whatever database you need in between. Stay away from stored procedures
> and anything that can't be done easily on another database (i.e. avoid
> proprietary features). Reading is easier to cache than writing.
>    
Funny, but "stored procedures" are probably the best way to implement a 
lot of functionality. They are "pre-compiled" by the databases, are 
faster than raw queries, and can be modified without touching the web 
code. My advice is to avoid databases that don't have such features. I 
could start my "don't even think about using MySQL rant."

> Does that help?
>    
I appreciate your comments. I wasn't really looking for advice so much 
as opinions and discussions about Oracle's stance on Java and how it 
would affect plans.
> I'm not a programmer, I'm a sysadmin. Stuff needs to be deployed; these
> are tools which are known to work.
> -dsr-
>