Slashdot Mirror
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?"
Google uses Java (gmail) Not really. They use JavaScript for that, which is quite different.
My sig is permanently on strike.
No question about it!
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.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
It does it all, and it values the most expensive component of software (for all but the biggest Web apps): programmer time.
Python is the way go to. For anyone who's built custom sites based on Zope, I think they would agree with me. Python is really easy to use for building big apps for use in web stuff, and Zope provides an easy-to-code-for application server.
Hi there
Microsoft ASP.NET is also an alternative. It's fairly new but the new MSDN is written in asp.net 2.0. It's a mixed application between parsed stuff (like traditional asp and perl) and compiled stuff like Java, C++. Couple benchmark proved that this was faster that Java. Not platform independant for now, but it's a mather of time with mono.
Microsoft uses ASP (what else?).
.net
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
The war with islam is a war on the beast
The war on terror is a war for peace
Ruby on Rails, try it, you won't want to use anything else. Ruby on Rails is just so sweet, just like the original Java alpha was all those years ago.
threadeds blog
I still use PHP for a lot of personal work and quick stuff, but I've been leaning more and more on Python, Zope, and Plone for building stuff at my day job. If you need to quickly and easily implement role based security, Zope makes it drop dead easy because it's built in and through ZEO, zope apps can be highly scalable. Of course as with most things, use whatever technologies get the job done. For example, my Zope apps live behind an Apache server that I use for SSL as well as access control.
To the making of books there is no end, so let's get started
Ajax, which stands for Asynchronous JavaScript and XML, does not necessarily imply Java on the backend. Many Web application frameworks, such as Ruby on Rails, include Ajax helpers. I'm sure many Java Web app frameworks have also added support for it.
Adaptive Path has a nice article introducing Ajax called Ajax: A New Approach to Web Applications.
Perl is a write-only language
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.
"Yarrgh! I be just a paintin' of a head..."
AJAX makes an HTTP request (using Javascript) which returns XML. The backend can be written in any language (Java, PHP, Perl, whatever).
Example
if(!cool) exit(-1);
Large standard library :-P
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
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
Physicists get Hadrons!
mod_perl is fast enough.
It's also fast enough for Amazon (they use mod_perl with HTML::Mason AFAIK).
saying that E-Bay uses ISAPI / C may be oversimplifying things. I see that some of their url's still include isapi.dll, which does suggest using ISAPI. But they had gone on the public record a few years ago as saying they were migrating to Java / J2EE, specifically IBM WebSphere software.
a ppdev/story/0,10801,63692,00.html
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?
// TODO: Insert Cool Sig
However, I would find such a system to be extremely unsuitable as a general-purpose database.
The World Wide Web is dying. Soon, we shall have only the Internet.
yeah, there is a huge difference between the two. With Visual Studio ASP.net has been by far the simplest web dev environment i have used. It seems the story submitter didn't bother doing any research becasue of the MS factor. That unfortunate becasue ASP.net is actually really fast and really good.
The war with islam is a war on the beast
The war on terror is a war for peace
With confidence I can say that C++ is the best choice of a language for developing large-scale applications. As any experienced developer know there are numerous reasons: portability, scalability, performance, etc. etc.
The only reason people think they use ISAPI is because that's what they originally used, and an executive decision was made to not break any existing links at any time, ever. Check the Powered by Java image. The /ws/eBayISAPI.dll that you see in all of the requests just invokes a servlet.
Holy mother of Jesus. I have to program that heap of tripe for years now. And my boss decided to write a large system in Notes with a mathematics student and I had to take the project over. The last five years have been hell.
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.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
But again, many of the worst issues are programmer rather than language issues.
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.
This sig has been temporarily disconnected or is no longer in service
I hear people saying all the time that they are not using J2EE when in fact what they mean is that they are not using the very bloated and usually difficult to develop (and slow) Enterprise JavaBean platform - EJB. When you are using the stack you mentioned you are using a very large part of J2EE - JDBC, JSP, and JNDI most likely. There is a whole suite of technologies that fall within J2EE - most are just fine, EJB being the primary exception.
I think that Java is the gold standard for small and large web portals in terms or reliability, good performance, etc. I have done portals that simply use Tomcat with either Prevayler or Hibernate/JDBC for persistence that basically run forever, until we want to do a software upgrade.
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.
20k lines of code? That is miniscule. I've got a mid-sized enterprise system that's got 20k FILES containing millions of lines of code integrating a dozen desparate systems over a network of 50 or so servers. It handles thousands of concurrent users performing transactions - not just viewing content. That's just a mid-sized system. Some large scale systems use clusters of hundreds of servers. Not to bash what you're doing but I think you could use a little perspective on the size of your application.
0 2-jperf_p.htmlo mmti-systems.de/main-Dateien/reviews/languages/ben chmarks.html& CFTOKEN=101A9EF8-9F8D-153A-37A5E0A40D3EE24A
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.
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.
Newsfollow.com
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
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
Take a look and feel free: http://www.PieMenu.com
#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.
FYI, features 1, 5, 6, and 9 are all supported in VS.Net by using Resharper. I couldn't imagine using VS.Net without it...
I just asked a female. She said pearls were definitely better than a C+.
The database interface pretty much encourages SQL-injection friendly logic, and the "Magic Quotes" hack that PHP came up with is just disgusting. Compare that to Java where programmers are encouraged to use safe Command and Parameter objects, or just abstract the SQL generation away with Hibernate etc.
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?