Я упереджений (будучи експертом Python, але досить іржавий у Java), але я думаю, що час роботи GAE Python в даний час є більш розвинутим і краще розвинутим, ніж час виконання Java - колишній мав ще один рік, щоб розвиватися і дозріти, зрештою .
Як далі будуть йти справи, звичайно, важко передбачити - попит, ймовірно, сильніший на стороні Java (тим більше, що мова йде не тільки про Java, але й про інші мови, що розташовані на вершині JVM, тому це спосіб запустити, наприклад, PHP або Ruby-код у App Engine); Однак команда Python App Engine має перевагу в тому, щоб на борту знаходився Гвідо ван Россум, винахідник Python та надзвичайно сильний інженер.
З точки зору гнучкості, двигун Java, як уже згадувалося, пропонує можливість запускати байт-код JVM, виготовлений різними мовами, а не лише Java - якщо ви знаходитесь у багатомовній крамниці, це досить великий позитив. І навпаки, якщо ви ненавидите Javascript, але мусите виконувати якийсь код у веб-переглядачі користувача, Java GWT (генеруючи Javascript для вас з кодування на рівні Java) є набагато багатшим і досконалішим, ніж альтернативи на стороні Python (на практиці, якщо ви хочете Python, ви будете писати деякі JS для цієї мети, тоді як якщо ви вирішите Java GWT - це зручна альтернатива, якщо ви не любите писати JS).
Що стосується бібліотек, то це досить-таки помилка - JVM досить обмежений (жодних потоків, жодних завантажувачів користувальницького класу, не JNI, ані реляційних БД), щоб перешкодити простому повторному використанню існуючих бібліотек Java на більшу кількість або більше, ніж існуючі Python аналогічні обмеження на час виконання Python перешкоджають бібліотеки.
Щодо продуктивності, я думаю, що це помилка, хоча вам слід орієнтуватися на власні завдання - не покладайтеся на ефективність високооптимізованих реалізацій JVM на основі JIT, знижуючи їх великі час запуску та слід пам’яті, оскільки двигун програми навколишнє середовище сильно відрізняється (витрати на запуск виплачуються часто, оскільки екземпляри вашої програми запускаються, зупиняються, переміщуються до різних хостів тощо), все, мабуть, для вас - такі події, як правило, набагато дешевші в середовищі виконання Python, ніж у JVM).
Ситуація XPath / XSLT (бути евфемістичною ...) не зовсім ідеальна в обидві сторони, зітхання, хоча я думаю, що це може бути менш поганим в JVM (де, мабуть, значні підмножини Saxon можуть працювати , з певною обережністю). Я думаю, що варто відкрити випуски з питань видання з XPath та XSLT у своїх заголовках - зараз є лише проблеми із запитом конкретних бібліотек, і це короткозорість: мені не дуже важливо, як реалізується хороший XPath / XSLT, для Python та / або для Java, доки я нею користуюся. (Конкретні бібліотеки можуть полегшити міграцію існуючого коду, але це менш важливо, ніж можливість виконувати такі завдання, як "швидке застосування XSLT-перетворення" якось! -). Я знаю, що зіткнувся б із такою проблемою, якщо це добре сформульовано (особливо в незалежно від мови).
І останнє, але не менш важливе: пам’ятайте, що ви можете мати різні версії свого додатка (використовуючи один і той самий сховище даних), деякі з яких реалізовані під час виконання Python, деякі з режимом виконання Java, і ви можете отримати доступ до версій, які відрізняються від "за замовчуванням / активним" "один із явними URL-адресами. Таким чином, ви можете використовувати і Python, і Java-код (у різних версіях програми) та змінювати один і той же сховище даних, надаючи вам ще більшу гнучкість (хоча лише одна матиме "приємну" URL-адресу, наприклад foobar.appspot.com - що, мабуть, важливо лише для доступу інтерактивних користувачів до браузерів, я думаю ,--).
