Thanks everyone for the great replies! My curiosity extends beyond just python's suitability as an enterprise level language. It seems the most compelling argument for java over python (and ruby) is python's difficulty with concurrency. However, when thinking about applications that are request based, I have difficulty thinking of common uses for concurrency, aside from the most extreme processing requirements.. in which case with python you would best off dropping into C and ultimately being more efficient (and you could disable the GIL and fire up some threads).
The exception, i gues, would be transactions, which I have not had to deal with in detail at the scale in which I work. I am still looking for the key to what 'enterprise' is, and I am curious what the use of concurrency is in the "enterprise level". Is it for transactions? What are the major challenges with transactions? If anyone knows any articles/papers to this effect that would also really be appreciated. Thanks! -Nikolaj On 9/18/07, Christopher Smith <[EMAIL PROTECTED]> wrote: > -----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 > -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
