-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gabriel Sechan <[EMAIL PROTECTED]> writes: > Over python, or in general? Over python, I have no clue. I haven't > studied python scalability. In general- its scalability isn't very > good. I work at Amazon, and there's a good mix here of C++ and Java > back end services. All the ones that have to truely scale are > written in C++. The problem with Java is that its scalable until it > isn't. A C++ program tends to have a peak, then a decent. Java is > more like a wall. It works, then suddenly the process garbage > collects for 5 minutes. Or starts to thrash like mad due to the 5 > billion threads Java spawns. I've seen more than 1 Java service > just hit a wall and completely crash (which then caused the LB to > send it to the next instance, which completely crashed, cascading > into system failure). If you want real scalability, its C++ or C.
So, I wrote a blog entry after Joel made similar comments (to the Python comments) about Ruby: http://xblog.xman.org/articles/2006/09/12/on-efficiency-scalability-and-the-wisdom-to-know-the-difference Sorry if that link has problems loading. My blog is currently suffering some mysterious issues. Reload helps. In general, it is silly to talk about scalability problems of a language. Most languages are far too flexibile for them to actually impose scaling limitations. Anyway, a LOT of the time people are talking about efficiency when they say scalability, and in the case of Google (or Amazon or Yahoo), this actually makes some sense. When you are scaling to 10 or 20 machines, efficiency is much less of a concern than scalability. When you start talking about thousands of machines, the story is different: scalability is no less important, but suddenly efficiency really starts to matter too. Why? Because it can mean the difference between one thousands machines vs. five thousand. That works out to a lot of $$'s. In this regard, Python really does leave a lot to be desired compared to Java. Python's CPU efficiency leaves a lot to be desired, and various other aspects of its design do nothing to help with that. Of course, refactoring a few key pieces of Python in to C++ will usually be enough to solve the problem, but that is not always the case. As for Java hitting "the wall".... That is really only true if you are talking about a specific brand of Java. When people talk about Java being great for "scalability", they often are referring to J2EE application servers. If you program to the framework, these servers will provide you a certain level of "no code changes" scalability. Unfortunately, due to a combination of the shortcomings of the spec, shortcomings of the products, and the general challenges of scaling, they do indeed hit a "wall". If you are clever you can push them a bit past the wall, but to really go way past it you often have to drop outside of the J2EE world (or leave it behind all together). Unfortunately, J2EE is such a massive spec people tend to barely learn how to use it and never really go past there to figuring out how to get it to perform well (or do the critical thinking around whether J2EE is the right fit for their problem). So people think they are hitting a "wall" in Java, but it is really in the app server they are working with. Java doesn't even come close to spawning 5 billion threads nor does it need to... but lots of app servers do, because that is what makes sense (sort of? ;-) in a J2EE world. Similarly, the notion of being blocked for 5 minutes is kind of laughable. Modern VM's do parallel GC, incremental GC, etc., not to mention the perfectly sane solution of having multiple processes with smaller heaps. Anyway, Java can scale, Python can scale, most anything can scale. For efficiency... Python isn't going to cut it. Java can do pretty well, but of course C/C++ give you more knobs to play with (the nice thing with C/C++ is if you get desperate you can always implement Java ;-). - --Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG75AGOagjPOywMBARAnv0AJ0X+i2TqWa9ilrwiHRIn9cMzw6fFACeKJYf 4ivuEmsbLwSjH4DoJR0g2PA= =SKXh -----END PGP SIGNATURE----- -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
