Choice of Language for Large-Scale Web Apps? 801
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?"
Re:Polyglot (Score:2, Informative)
Java Java Java! (Score:4, Informative)
performance, scalability, extendibility, cost of development (man-month), availability of libraries, cost of libraries, development tools
Performance? Assembly will give you the best performance followed by C and C++. All three of do not have that great of support for web apps..
However, Java is almost exclusively being used for large enterprise websites. Its powerful enough to handle the big jobs, and using the appropriate app server will give you great performance.
Cost of development is heavy in initial development, but pays for itself in maintenance. Most libraries and APIs are free in java (struts, spring, hibernate, tapestry, etc etc etc...). I'd say they are second to perl in terms of freely available and powerful libraries and APIs.
Development tools? Just check out the (free!) eclipse platform.
In my mind there is no question that Java (more specifically J2EE) is the best option for general large scale enterprise applications.
Seconded! (Score:3, Informative)
Python (Score:4, Informative)
ASP.NET (Score:1, Informative)
Microsoft (Score:2, Informative)
err, no. MS does not use asp, they use ASP.net. There is a BIG difference between the two. The former is VB and the latter is C#,VB.net,J#,managed c++ etc etc. basically any language that runs in
Ruby on Rails (Score:3, Informative)
Python, Zope, and Plone Are Good (Score:3, Informative)
Re:Polyglot (Score:5, Informative)
Adaptive Path has a nice article introducing Ajax called Ajax: A New Approach to Web Applications [adaptivepath.com].
Re:Perl? (Score:2, Informative)
O, if only mod points hath I.
AC is right. Perl is not the best choice as far as upkeep goes. This is especially true if you get those l33t p3rL haXX0rzzZ who feel the need to program in circles.
What is a better language than perl? Why, Ruby! (and not just because of Rails) However, for large projects where performance may be a significant factor, the answer for many of the back-end logic stuff would be something more like C/C++.
I agree with many other people posting. The language itself is not important. Good design and good people are what leads to good code. The language is only a tool.
Re:Polyglot (Score:3, Informative)
Example [phpbuilder.com]
ASP.NET... no, really (Score:4, Informative)
Excellent MVC model
Integrated caching capabilities
You can compile your libraries before uploading
Excellent Web Services model
Free tools
Works on Linux (through mono)
Large third party support
Very Fast
Easier to use and deploy than J2EE
Re:Depends on what you want to do... (Score:5, Informative)
What people mean by 'it doesn't scale' is that it doesn't scale. Not that it doesn't run fast enough or have enough functionality for pretty much anything at the small-to-medium sized website...
I have a set of 200 or so websites all running though a self-built PHP template-based content-management system (hey, this was 8 years ago, they were rare then!
And will all those features it's still not scaleable. I can't split the system over multiple webservers and begin a transaction on one webserver, have a hardware failure, and have it complete on a different webserver.
I server about a million page-impressions a day (less at weekends) so I'm hardly "big iron", but at the moment it's all serving from a single machine(*) with a manual backup ready-to-go. We're (probably) about to triple our daily throughput (time to splash some cash
I can't have the above level of scalability but I can divide up the work over (say) 4 cloned webservers, and use round-robin DNS (low TTL) or transparent-proxy load-balancing to share the load. Then at least if one of the machines goes down (not the proxy
We're probably going to have 2 database servers as well - one in slave mode, one in master mode (all writes to the master, because we use MySQL). The single point of failure then becomes the proxy gateway (because RR DNS is a bit of a pain), so we can have a spare standing by - the configuration of a load-balancing proxy is pretty trivial, and doesn't depend on anything else, so it can be sitting ready to run and swapping ethernet patch cables ought to be all that is necessary.
And that's about as "scalable" as I can make it - not very. All I'm doing is duplicating hardware for speed and reliability. I can have robustness against a machine dying, but that's about as far as I can go. True scalability allows the operation the machine was doing when it died to complete successfully, and PHP ain't there (yet). I guess you could implement it in s/w using lots of state tables, and perhaps get 80% of the way there, but it's an add-on not a built-in, and not a complete solution. Better to go with something that works if you need it...
Just MHO.
Simon
(*) It is a bit of a beast of a machine though
Re:ASP.NET... no, really (Score:3, Informative)
A vice-versa question could be asked of the grandparent as well, since neither of you provided any factual evidence either way.
Re:Perl. (Score:2, Informative)
It's also fast enough for Amazon (they use mod_perl with HTML::Mason AFAIK).
Re:ASP.NET... no, really (Score:2, Informative)
To deploy any changes, is just a matter of dropping 1 or 2 dll's into the bin directory and viola, it's deployed. Tell me again how hard that was?
Are you sure about E-Bay? (Score:4, Informative)
http://computerworld.com/softwaretopics/software/
I would guess that they're actually using a mix of technologies. Any insiders have any insight they can share? Even anonymously?
Re:Polyglot (Score:4, Informative)
However, I would find such a system to be extremely unsuitable as a general-purpose database.
Re:Microsoft (Score:2, Informative)
C++ best choice for larg-scale apps (Score:1, Informative)
Actually, eBay uses Java. (Score:5, Informative)
Re:Lotus Domino (Score:3, Informative)
Notes's web part is not too bad and its unbeatable for putting up a really quick form for people to use if the looks are not too important but the database is utterly atrocious.
the other problem with Notes is the horrifying development environment. You cannot, for instance, search your code and while it throws out line numbers in errors you cannot see them! And it does crap like no functionn (despite being in different modules) mmay have the same name in a system. The linker does not work. It does not support CGI hheaders properly. And you have to predefine ANY search through the database, there is no dynamic query language like SQL. This is probably the worse part of the whhole piece of shit.
Notes as a mail system is not too bad however. It really handles the case where mmails are not sent correctly quite well, because it remembers the mail it send in a database.
The notes client itself is not too bad, there are things it does OK.
Anyways, stay away. Far, far away. Don't be like me and be trapped in this cesspool of horror.
Re:Hmmm.... (Score:4, Informative)
While that's true, each language has semantics that either encourage or discourage their worst behaviors.
As far as Java in regards to your comments above. Java's scripted aspects are actually compiled into code and turned into byte code before run. So the first time a page runs, it will be slow because of conversion. Once run the first time it will be as fast as the compiled code.
As far as the issues of compiled code, development evironments for java really make a lot of this process quite easy. If you make changes to your code that don't require changes to method signatures, just the chunk of code you modified can be re-compiled. In NetBeans, what I use, I just click a button, and my code is ready to test in less than second.
EJB != J2EE (Score:1, Informative)
Java, Ruby on Rails, Python, Smalltalk,Common Lisp (Score:3, Informative)
That said, for CRUD applications, RoR is good - the scaffolding gets you up and running quickly, and views, controllers, etc. are easily customized.
I used to use Python and Common Lisp a fair amount, but not recently. The UnCommon Web Common Lisp package looks good; I would like to check it out in some detail when it is more mature. It uses continuations (like Seside for Squeak and VisualWorks Smalltalk) to manage state between web pages.
Sure, there is some overhead for using multiple langauges and frameworks, but I have always believed that it is best to be a "generalist" who can drill down when required.
Re:Hmmm.... (Score:4, Informative)
I don't care if you've got a freakin army of PHP programmers, you're never going to build a system that can scale like Java.
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.
Don't believe the hype about Java's performance. Today's just-in-time compilers can optimize code as well as hand optimized code and they don't waste resources optimizing paths that don't get executed. There are many benchmarks out there that confirm that Java's performance is comparable to C++ and even better in some areas.
http://www.javaworld.com/javaworld/jw-02-1998/jw-
http://www.tommti-systems.de/go.html?http://www.t
http://java.sys-con.com/read/45250.htm?CFID=29694
I agree with your point though, there are a huge number of crappy programmers out there. Good programmers write good code in whatever language they are using.
So, what is good code?
IMHO, good code performs well and is easy to understand and use.
Re:Depends on what you want to do... (Score:5, Informative)
Then I guess you never heard about using database driven sessions. The way how you've designed that bad boy, it would'nt scale in any language.
Here's what we do:
- 8 Apache Webservers
- 3 Million pageviews per day
- Distributed PHP sessioning (Postgresql based)
- PHP module
- Postgresql (no worries with MySQL write locks)
Scaling? We add new machines in the mix, tell our load balancer about the new machines, and we've scaled linearly. A machine goes down? The load balancer redirects to another machine and the session continues without a beat.Bottleneck? The database, but then you throw big iron at that.
Look, the web is stateless, if applications are designed from the get-go realizing that fact, heck, you can get a shell script sitting in cgi-bin to scale with your server pool.
There's absolutely nothing in PHP that inherently causes it not to scale. Sure, other languages have easier and sometines better features built in, but if you're already using PHP, implementing those features are usually worth the few programming hours of effort instead of switching to another language/platform.
Re:Polyglot (Score:2, Informative)
I'm guessing he probably doesn't know either. More likely this is what he meant:
As to your question I found this:
For more info, http://mirrors.ccs.neu.edu/MOO/html/ProgrammersMan ual_9.html#SEC9 [neu.edu]
You'r dead wrong about Lisp (Score:3, Informative)
Are you going to trot out the "parenthesis are hard to read" argument? Well take a look at XML: that has TWICE THE NUMBER OF PARENTHESIS, only they're pointy instead of curved. That old "I'm afraid of parenthesis" argument is bullshit.
Now look at Perl code: instead of seeing the explicit, unambiguous parenthesis in the code, you have to remember and resolve all of the implicit and complex special syntax rules, punctuation, precidence order, left/right evaluation, contextual quirks and special cases, etc.
If you think Lisp is harder to read than Perl, then you obviously don't know either language, and you're just basing your beliefs on rumors you heard ignorant people distort and repeat, without learning those languages for themselves.
-Don
4 lanuages is the minimum... (Score:2, Informative)
#3 is where there's the most flexibility. Speaking very generally, there are two ways to go:
a. Lightweight scripting systems that depend only on the web server (probably with a loaded module) for support. Typically PHP, Perl, Python, or JSP/ASP using Java or a Microsoft language.
b. Heavyweight systems, of which the two most common are J2EE and .NET. J2EE uses Java as its language, and .NET usually uses C# or VB.
The usability, performance, etc., of the heavyweight systems depend as much on the middleware as the language itself. .NET is .NET, but for J2EE there are several choices. In my own experience with heavyweight systems, I found Java to be wonderful, but our J2EE server (Oracle's) very difficult to work with operationaly, and way too complicated for what we needed. So, in my opinion, one has to have much education, experience, and patience if one is to use a heavyweight system.
My conclusion, however, would be that a heavyweight system is the correct choice for a big web application. My bias is towards J2EE because it's more open (and even has open source choices available), but the complexity of J2EE servers is a big concern.
From what I hear, .NET has superior development tools and better support. I don't know whether this is (a) true and (b) worth the disadvantages of using a proprietary system.
Re:Not all true (imo) (Score:3, Informative)
Re:Everything, huh? (Score:1, Informative)
Re:You are contradicting yourself. (Score:1, Informative)
PHP's oracle API lets you compile statements and then bind variables to them, which makes SQL injection impossible.
I've just checked the documentation and the mysqli API and postgresql API also offer variable binding.
Variable binding is the surest way to avoid SQL injection problems, and it is exposed by the API's for the major databases in use. So, what, exactly, is the problem with PHP's API's again?