Choice of Language for Large-Scale Web Apps?

anyon wonders: "PHP is the most popular language for the web. eBay uses ISAPI (C), Google uses C/C++ (search), Java (gmail), and Python. Microsoft uses ASP (what else?). For small web site, it really doesn't matter. What's your take on language choice for large-scale web applications? Maybe language choice is irrelevant, only good people (developers) matter? If you can get the same good quality people, then what language you would chose? Considering the following factors: performance, scalability, extendibility, cost of development (man-month), availability of libraries, cost of libraries, development tools? Has there been a comprehensive comparison done?"

Comments

Who do you have?

[rob_squared]

Smarter people than myself have said it, if the people you have know a certain language, use that, don't force them to use something else even if it is conceived to be better. Now if you're going out and specifically hiring people for this project, things get a whole lot more touchy-feeley and you'll be forced to do much research. But then again, you're probably expecting to do a lot of that anyway.

WebObjects

[lightningrod220]

Apple uses WebObjects for its online store and the iTunes store. Consider that those go under a lot of stress. Those seem to be the biggest examples of its use, so I don't know what kind of performance it does in other situations. But for an all-around package, it seems to be pretty good.

PHP

[AVryhof]

We have a small website (85,000 hits a day)

So here's the rundown of what we use...
CGI/Backend: PHP

Client Side: Javascript

Presentation: CSS/HTML 34 (Somewhere between 3.2 and 4)

Then of course there is the PHP and static generated RSS feeds.

Re:What about security?

[jadavis]

Perl, Python, and Ruby are handy because they have an interface to C. You never find yourself without a module if you can just make a wrapper for C.

Although I haven't tried it, you can get similar benefit from using Jython. Having two languages like Python and Java at your disposal has got to be a godsend for a large web app. I'm not sure if you still get to use C modules if using Jython.

Please stop insulting python.

[Some Random Username]

You can certainly make a large, high traffic site in python. But not with zope. Zope is brutally slow, and the only thing you can do about it is shove a cache infront of it, which does nothing to help speed up user-specific content.

Just use a decent python web framework with a real webserver, zope is a waste of time.

Python + PHP + XML-RPC

[MikeFM]

A solution I like is to write a Python backend that is exposed to the frontend as XML-RPC. Then use the language your designers find easiest to work in for front-end coding.. usually PHP.

Python is great for the backend because it has good namespace support which helps a lot for big complex programs. PHP on the other hand is well known and extremely easy for doing various web-scripting type tasks. I have a little PHP function that gets called by the PHP server for every page (without needing to be in the code exposed to the PHP coders) that simply passes the page inputs to Python over XML-RPC and puts the response into a global variable. Then the PHP coders jut display the results however needs to be done based on the inputs and outputs.

Some nice benefits of such a split system is that it's easy to keep UI logic sepperate from application logic and it's easy to split your application up over multiple servers so that it can scale to any load. For example you might have two PHP servers, three Python servers, and a DB server dividing the load. Normal load balancing techniques work just fine for deciding how the machines talk to each other. Pretty nice to be able to just throw another server in where it's needed if you suddenly find a 9/11-type day where your site is getting unexpectedly high loads.

Of course you can split your processing up in more levels if you need to. I like to abstract out all my queries into their own XML-RPC interface that sits in front of the DB so as to not allow direct access to the DB for security reasons. Anyone trying to hack the DB would have to use my stored queries and work through my XML-RPC interface rather than being able to access the DB directly. If your dealing with sensitive information it's just another layer of protection. If you have to access third-party systems that use some unstandardized method of communicating then it can help to keep your code clean if you create a proxy interface between those systems and your own that speaks XML-RPC. This way the code for speaking to that other system is a completely sepperate code base and your main code base is kept clean.

Hmmm....

[einhverfr]

I actually like PHP for large-scale web apps. However, I agree that many PHP programmers do create unmanageable code. This is, however, a programmer issue rather than a language issue.

I started writing HERMES (a CRM framework/app) in PHP and it is now over 20k lines and when I have time to add enhancements it will grow again. The code is incredibly manageable simply because the complexity of the application meant that I had to divide the code into four main areas (each handled in different sets of files):
1) Main engine(s)/UI framework
2) UI generation code/data input screens
3) UI event handling code
4) Core object logic.

This way, if you want to change the user interface, you just change the user interface. System-wide changes get made in one place where screen-specific changes get made somewhere else.

Everything is relatively well abstracted, so the code is very manageable.

Now, other languages have very specific problems associated with them:

1) Scripted languages in general: slow performance

2) Compiled languages in general: Requires rebuild before changes take effect, so testing and retesting is slowed down.

3) Java/.Net/Byte-code languages: Worst of #1 and #2 above.

4) Python: Performs a little better than most scripting languages, but there are times when its reference-based structure can cause bugs to be very difficult to find.

5) PHP: Many PHP programmers write readible but unmaintainable code.

6) Perl: Many Perl programmers write maintainable but unreadible code.

7) LISP: See Perl only even more so.

8) ASP. ASP is only really useful in large apps when paired with COM objects written in C++ or VB. So you have the problems with a scripted language combined with the problems of compiled languages.

But again, many of the worst issues are programmer rather than language issues. Then again, depending on your project, you may have to eliminate possibilities because of language capabilities.