Я предвзято (будучи экспертом по Python, но довольно хорошо разбираюсь в Java), но я думаю, что среда исполнения Python для GAE в настоящее время более продвинута и лучше разработана, чем среда исполнения Java - у первого был еще один год на разработку и развитие, в конце концов ,
Как будет развиваться ситуация в будущем, конечно, трудно предсказать - спрос, вероятно, сильнее на стороне Java (тем более, что речь идет не только о Java, но и о других языках, расположенных на вершине JVM, так что это способ запускать, например, PHP). или код Ruby в App Engine); однако команда разработчиков Python App Engine имеет преимущество в том, что на борту есть Гвидо ван Россум, изобретатель Python и удивительно сильный инженер.
С точки зрения гибкости, движок Java, как уже упоминалось, предоставляет возможность запуска байт-кода JVM, созданного на разных языках, а не только на Java - если вы находитесь в многоязычном магазине, это довольно большой плюс. И наоборот, если вы ненавидите Javascript, но должны выполнить некоторый код в браузере пользователя, GWT в Java (генерирующий Javascript для вас из вашего кода на уровне Java) будет гораздо богаче и более продвинутым, чем альтернативы на стороне Python (на практике, если вы выберете Python, вы сами напишете JS для этой цели, в то время как если вы выберете Java, GWT будет полезной альтернативой, если вы не любите писать JS).
С точки зрения библиотек это в значительной степени промывка - JVM достаточно ограничен (без потоков, без пользовательских загрузчиков классов, без JNI, без реляционных БД), чтобы затруднить простое повторное использование существующих библиотек Java на столько же или больше, чем на существующих Python. библиотекам также мешают подобные ограничения на время выполнения Python.
С точки зрения производительности, я думаю, что это мойка, хотя вы должны сравнивать свои собственные задачи - не полагайтесь на производительность высокооптимизированных реализаций JVM на основе JIT, не учитывающих их большое время запуска и объем памяти, потому что механизм приложения среда очень разная (затраты на запуск будут часто оплачиваться, так как экземпляры вашего приложения запускаются, останавливаются, перемещаются на разные хосты и т. д., как вы понимаете, такие события обычно намного дешевле в средах выполнения Python, чем в JVM).
Ситуация с XPath / XSLT (чтобы быть эвфемистической ...) не совсем идеальна с обеих сторон, вздох, хотя я думаю, что это может быть не так уж плохо в JVM (где, по-видимому, можно использовать существенные подмножества Saxon для запуска) с некоторой осторожностью). Я думаю, что стоит открывать Appengine Issues странице с XPath и XSLT в их заголовках - сейчас есть только вопросы, требующие определенных библиотек, и это близоруко: мне все равно, КАК реализован хороший XPath / XSLT, для Python и / или для Java, пока я использую его. (Определенные библиотеки могут облегчить миграцию существующего кода, но это менее важно, чем возможность выполнять такие задачи, как «быстрое применение преобразования XSLT» НЕКОТОРЫМ способом! -). Я знаю, что я бы отметил эту проблему, если бы хорошо сформулировал (особенно не зависящим от языка).
И последнее, но не менее важное: помните, что у вас может быть другая версия вашего приложения (с одним и тем же хранилищем данных), некоторые из которых реализованы с помощью среды выполнения Python, другие - с средой выполнения Java, и вы можете получить доступ к версиям, отличным от «default / active». "один с явными URL. Таким образом, вы можете использовать как код Python, так и код Java (в разных версиях вашего приложения) и изменять одно и то же хранилище данных, предоставляя вам еще большую гибкость (хотя только один будет иметь «красивый» URL, такой как foobar.appspot.com - я думаю, это важно только для доступа интерактивных пользователей в браузерах ;-).
