Выбор Java против Python в Google App Engine

В настоящее время Google App Engine поддерживает как Python & amp; Джава. Поддержка Java менее развита. Тем не менее, Java, кажется, имеет более длинный список библиотек и особенно поддерживает байт-код Java независимо от языков, используемых для написания этого кода. Какой язык даст лучшую производительность и большую мощность? Пожалуйста, порекомендуйте. Спасибо!

Edit: http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1

Edit: "Силой" Я имею в виду лучшую расширяемость и включение доступных библиотек вне рамок. Python допускает только чистые библиотеки Python.

 Michele Giuseppe Fadda25 нояб. 2015 г., 21:41
@pinouchon Я начал использовать Go и внедрил его в производство на GAE. GO очень хорошо работает на GAE, компилируется за несколько секунд. Выберите свой веб-фреймворк с умом :-)
 Benjamin Crouzier15 июл. 2011 г., 12:52
сейчасGoogle App Engine is supporting Иди (экспериментально). Что вы думаете об этом?

Ответы на вопрос(15)

Ушел с Python, хотя GWT кажется идеальным выбором для приложения, которое я разрабатываю. JPA довольно запутан в GAE (например, нет @Embeddable и другие неясные недокументированные ограничения). Потратив неделю, я могу сказать, что на данный момент Java не совсем подходит к GAE.

Это хороший вопрос, и я думаю, что многие ответы дали хорошие точки зрения на плюсы и минусы по обе стороны забора. Я пробовал и Python, и основанный на JVM AppEngine (в моем случае я использовалGaelyk который представляет собой Groovy каркас приложения, созданный для AppEngine). Когда дело доходит до производительности на платформе, то, что я не рассматривал до тех пор, пока она не смотрела мне в глаза, это значение «Загрузка запросов». которые происходят на Java стороне забора. При использовании Groovy эти запросы загрузки являются убийцей.

Я собрал пост по теме (http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/) и я надеюсь найти способ обойти эту проблему, но если нет, думаю, я вернусь к комбинации Python + Django, пока холодный запуск Java-запросов не окажет меньшего влияния.

Прелесть питона в наши дни в том, насколько хорошо он общается с другими языками. Например, вы можете использовать Python и Java в одной таблице с Jython. Конечно, jython, хотя он полностью поддерживает библиотеки Java, он не поддерживает полностью библиотеки Python. Но это идеальное решение, если вы хотите возиться с библиотеками Java. Он даже позволяет смешивать его с кодом Java без дополнительного кодирования.

Но даже сам Python сделал несколько шагов вперед. См., Например, ctypes, около C speed, прямой доступ к библиотекам C - все это, не выходя из удобства программирования на python. Cython делает еще один шаг вперед, позволяя с легкостью смешивать код c с кодом Python, или даже если вы не хотите связываться с c или c ++, вы все равно можете кодировать на python, но использовать переменные статического типа, что делает ваши программы на python такими же быстрыми, как приложения на C , Кстати, Cython используется и поддерживается Google.

Вчера я даже нашел инструменты для Python для встроенного C или даже Assembly (см. CorePy), вы не можете получить более мощный, чем это. ,

Python, безусловно, является очень зрелым языком, не только стоящим на себе, но и способным легко взаимодействовать с любым другим языком. Я думаю, именно это делает Python идеальным решением даже в очень сложных и сложных сценариях.

С python вы можете получить доступ к C / C ++, Java, .NET и многим другим библиотекам с почти нулевым дополнительным кодированием, что также дает вам язык, который минимизирует, упрощает и украшает кодирование. Это очень заманчивый язык.

 13 апр. 2012 г., 03:58
Я согласен с @Daniyar, что этот ответ немного (или, возможно, полностью) не в ритме, но мне нравится ответ, и это было то, что я искал. Спасибо Килону за то, что поделился этими знаниями. Может быть, это было не то место, но вы наверняка поделились знаниями. +1 и слава за это.
 03 авг. 2010 г., 06:53
Вопрос о java против python в GAE, который имеет много ограничений. Следовательно, ваши аргументы неприменимы.

Порожняя ласточка, который, по-видимому, финансируется Google, если не принадлежит Google. Они пытаются реализовать основанный на LLVM байт-код для Python 2.6.1, чтобы они могли использовать JIT и различные приятные оптимизации для собственного кода / GC / многоядерных процессоров. (Хорошая цитата: «Мы стремимся не делать никакой оригинальной работы, вместо этого используя как можно больше из последних 30 лет исследований».) Они ищут 5-кратное ускорение до CPython.

Конечно, это не отвечает на ваш непосредственный вопрос, но указывает на «сокращение разрыва»; (если таковые имеются) в будущем (надеюсь).

 Viet30 авг. 2009 г., 08:36
Спасибо :) Я посмотрю на это!
 09 нояб. 2011 г., 18:37
Unladen Swallow теперь мертвый проект и последний коммитover a year old.

Одна мысль, которую стоит принять во внимание, - это фреймворки, которые вы собираетесь использовать. Не все фреймворки на стороне Java хорошо подходят для приложений, работающих на App Engine, который несколько отличается от традиционных серверов приложений Java.

Необходимо учитывать время запуска приложения. С традиционными веб-приложениями на Java вам не нужно об этом думать. Приложение запускается, а затем просто запускается. Не имеет значения, занимает ли запуск 5 секунд или пару минут. С App Engine вы можете оказаться в ситуации, когда приложение запускается только при поступлении запроса. Это означает, что пользователь ожидает загрузки вашего приложения. Здесь помогают новые функции GAE, такие как зарезервированные экземпляры, но сначала проверьте.

Другое дело, разные ограничения GAE psoes на Java. Не все фреймворки довольны ограничениями на то, какие классы вы можете использовать или тем, что потоки не разрешены или что вы не можете получить доступ к локальной файловой системе. Эти проблемы, вероятно, легко обнаружить, просто взглянув на совместимость с GAE.

Я также видел, как некоторые люди жалуются на проблемы с размером сеанса в современных средах пользовательского интерфейса (а именно Wicket). В общем, эти структуры имеют тенденцию делать определенные компромиссы, чтобы сделать разработку веселой, быстрой и легкой. Иногда это может привести к конфликтам с ограничениями App Engine.

Сначала я начал разрабатывать GAE с Java, но затем перешел на Python по этим причинам. мойpersonal feeling в том, что Python - лучший выбор для разработки App Engine. Я думаю, что Java более "дома" например, на эластичном бобовом стебле Amazon.

BUT с App Engine все меняется очень быстро. GAE меняется сам по себе, и по мере того, как он становится все более популярным, платформы также меняются, чтобы обойти его ограничения.

Следите за изменениями в производительности Python и Java:

http://gaejava.appspot.com/ (редактировать: извинения, ссылка не работает. Но следующий пункт все еще применяется, когда я видел, что он работает в последний раз)

В настоящее время Python и использование низкоуровневого API в Java работают быстрее, чем JDO на Java,for this simple test, По крайней мере, если основной движок изменится, это приложение должно отражать изменения производительности.

 12 дек. 2010 г., 09:35
Я согласен избегать JDO, отчасти по той причине, о которой вы упомянули, а также потому, что она медленнее, чем низкоуровневая. (Что обычно показывает тест.) Он просто намекает на наличие различий в производительности, поэтому либо не используйте JDO, либо тестируйте для своей конкретной задачи. Я переместил весь свой собственный код из JDO и низкоуровневого API в Objectify. И в любом случае это также показывает, что Python, безусловно, не плохой родственник производительности в GAE.
 11 дек. 2010 г., 13:26
При всем уважении, я считаю этот тест достаточно простым, чтобы быть бессмысленным. Для чего это стоит ... Если вы используете Java / GAE, я рекомендую использовать API низкого уровня и избегать JDO или любой другой инфраструктуры. Что еще более важно, JDO дает вам «чувство» Вы работаете с реляционной базой данных, которая может вводить в заблуждение.
 19 апр. 2012 г., 20:54
Ваше приложение выдает внутреннюю ошибку сервера.
 23 янв. 2014 г., 14:57
я хотел бы увидеть, как объективизируется в этом тесте
 25 апр. 2012 г., 22:12
Спасибо, Том. Не мое приложение, к сожалению. Отправили по почте кого-то, кто может быть связан.

Как вы уже определили, использование JVM не ограничивает вас использованием языка Java. Список языков JVM и ссылки можно найтиВот. HoweverGoogle App Engine действительно ограничивает набор классов, которые вы можете использовать из обычного набора Java SE, и вы захотите выяснить, можно ли использовать какую-либо из этих реализаций в механизме приложения.

РЕДАКТИРОВАТЬ: я вижу, вы нашли такой список

Я не могу комментировать производительность Python. Однако JVM является очень мощной платформой с точки зрения производительности, учитывая ее способность динамически компилировать и оптимизировать код во время выполнения.

В конечном счете, производительность будет зависеть от того, что делает ваше приложение и как вы его кодируете. Ввиду отсутствия дополнительной информации, я думаю, что невозможно дать больше указаний в этой области.

 Viet06 июл. 2009 г., 10:16
Спасибо за быстрый ответ, Брайан. Я намерен сфокусировать приложение на извлечении URL-адресов и парсинге XML & amp; XSLT обработка. Будет меньше обслуживания HTTP-контента для браузеров.

Важный вопрос, который следует учитывать при выборе между Python и Java,how you will use the datastore in each language (и большинство других точек зрения на исходный вопрос уже достаточно хорошо освещены в этой теме).

For Javaстандартным методом является использование JDO или JPA. Они отлично подходят для переносимости, но не очень хорошо подходят для хранилища данных.

Доступен низкоуровневый API, но это слишком низкий уровень для повседневного использования - он больше подходит для создания сторонних библиотек.

For Python Существует API, разработанный специально для предоставления приложениям простого, но мощного доступа к хранилищу данных. Это здорово, за исключением того, что он не портативный, поэтому он блокирует вас в GAE.

К счастью, разрабатываются решения для слабых мест, перечисленных для обоих языков.

For Javaнизкоуровневый API используется для разработки постоянных библиотек, которые гораздо лучше подходят для хранилища данных, чем JDO / JPA (IMO). Примеры включаютСиенский проект, а такжеовеществлять.

Недавно я начал использовать Objectify и обнаружил, что он очень прост в использовании и хорошо подходит для хранилища данных, и его растущая популярность вылилась в хорошую поддержку. Например, Objectify официально поддерживается новой службой Google Cloud Endpoints. С другой стороны, Objectify работает только с хранилищем данных, в то время как Сиена «вдохновлена». хранилищем данных, но предназначен для работы с различными базами данных SQL и хранилищами данных NoSQL.

For Pythonпредпринимаются попытки разрешить использование API хранилища данных Python GAE за пределами GAE. Одним из примеров является серверная часть SQLite, которую Google выпустил для использования с SDK, но я сомневаюсь, что они намерены превратиться в нечто готовое к производству.TyphoonAE Проект, вероятно, имеет больший потенциал, но я не думаю, что он также готов к производству (поправьте меня, если я ошибаюсь).

Если кто-то имеет опыт работы с любой из этих альтернатив или знает о других, пожалуйста, добавьте их в комментарии. Лично мне действительно нравится хранилище данных GAE - я считаю, что это значительное улучшение по сравнению с AWS SimpleDB - поэтому я желаю успеха в этих усилиях по устранению некоторых проблем при его использовании.

Я настоятельно рекомендую Java для GAE и вот почему:

Performance: Java is potentially faster then Python. Python development is under pressure of a lack of third-party libraries. For example, there is no XSLT for Python/GAE at all. Almost all Python libraries are C bindings (and those are unsupported by GAE). Memcache API: Java SDK have more interesting abilities than Python SDK. Datastore API: JDO is very slow, but native Java datastore API is very fast and easy.

Я сейчас использую Java / GAE в разработке.

 09 мар. 2011 г., 18:53
@ Пол, если вы хотите, чтобы я рассмотрел эти вещи как часть вашего ответа, вы должны были включить их в свой ответ. Вместо этого вы включаете строку полуправды. Никто не выбирает язык на основе тех угловых случаев, которые вы сейчас придумали.
 07 сент. 2010 г., 16:32
@ Марк, извините за задержку. Я думаюcode.google.com/p/objectify-appengine сейчас лучший выбор.
 08 мар. 2011 г., 17:10
-1 за откровенную ложь в пунктах № 2 и № 3 и № 4 не имеет никакого смысла.
 Viet08 июл. 2009 г., 03:31
Спасибо Пол за рекомендацию.
 30 авг. 2010 г., 14:25
@Paul - не могли бы вы порекомендовать (или дать ссылки на) лучший способ обработки персистентности с использованием Java на GAE, если JDO не является подходящим способом?

June 2013: Это видео очень хороший ответ от инженера Google:

http://www.youtube.com/watch?v=tLriM2krw2E

TLDR; является:

Pick the language that you and your team is most productive with If you want to build something for production: Java or Python (not Go) If you have a big team and a complex code base: Java (because of static code analysis and refactoring) Small teams that iterate quickly: Python (although Java is also okay)

Исходя из того, насколько я слышу, что Java-люди жалуются на AppEngine по сравнению с пользователями Python, я бы сказал, что Python гораздо менее напряженный в использовании.

 17 дек. 2010 г., 14:13
Я слышал, что владельцы Ford жалуются на свои машины гораздо больше, чем владельцы Koenigsegg. Почему это может быть?

Я немного опоздал на разговор, но вот мои два цента. Мне действительно было трудно выбирать между Python и Java, так как я хорошо разбираюсь в обоих языках. Как мы все знаем, у обоих есть свои преимущества и недостатки, и вы должны учитывать ваши требования и рамки, которые лучше всего подходят для вашего проекта.

Как я обычно делаю в этом типе дилемм, я ищу цифры, чтобы поддержать мое решение. Я решил использовать Python по многим причинам, но в моем случае был один сюжет, который стал переломным моментом. Если вы ищете & quot; Google App Engine & quot; в GitHub сSeptember 2014, вы найдете следующую цифру:

GAE Language Stats

В этих числах может быть много смещений, но в целом, в три раза больше репозиториев GAE Python, чем в репозиториях GAE Java. Не только это, но если вы перечислите проекты по «количеству звезд» вы увидите, что большинство проектов Python появляются сверху (вы должны принять во внимание, что Python существует дольше). Для меня это убедительная аргументация в пользу Python, потому что я принимаю во внимание принятие сообщества & amp; поддержка, документация и доступность проектов с открытым исходным кодом.

Основываясь на опыте работы с этими виртуальными машинами на других платформах, я бы сказал, что вы, вероятно, получите более высокую производительность благодаря Java, чем Python. Однако не стоит недооценивать достоинства Python: язык Python гораздо более продуктивен с точки зрения строк кода - общее согласие состоит в том, что Python требует трети кода эквивалентной Java-программы, оставаясь при этом как более читаемым или более читабельным. , Это преимущество умножается на возможность немедленного запуска кода без явного шага компиляции.

Что касается доступных библиотек, вы обнаружите, что большая часть обширной библиотеки времени выполнения Python работает «из коробки» (как и Java). Популярный веб-фреймворк Django (http://www.djangoproject.com/) также поддерживается в AppEngine.

Что касается «власти», то трудно понять, что вы имеете в виду, но Python используется во многих различных областях, особенно в Интернете: YouTube написан на Python, как и Sourceforge (по состоянию на прошлую неделю).

 Viet06 июл. 2009 г., 11:59
Спасибо Judy2K! Под властью я имею в виду возможность делать больше вещей и легко расширяться.

Я был поражен тем, насколько чистым, понятным и беспроблемным является SDK Python / Django. Однако я начал сталкиваться с ситуациями, когда мне нужно было начать делать больше JavaScript, и подумал, что, возможно, захочу воспользоваться преимуществами GWT и других утилит Java. Я только что прошел половину учебного курса по Java для GAE и столкнулся с одной проблемой за другой: проблемы с настройкой Eclipse, версионит JRE, невероятная сложность Java и запутанный и, возможно, неработающий учебник. Проверка этого сайта и других, связанных здесь отсюда, подтвердила его для меня. Я возвращаюсь к Python и смотрю на пижаму, чтобы решить мои проблемы с JavaScript.

Решение Вопроса

Я предвзято (будучи экспертом по Python, но довольно хорошо разбираюсь в Java), но я думаю, что среда исполнения Python для GAE в настоящее время более продвинута и лучше разработана, чем среда исполнения 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 для запуска с некоторой осторожностью). Я думаю, что стоит открыватьПроблемы с Appengine страница с XPath и XSLT в их заголовках - сейчас есть только вопросы, требующие конкретных библиотек, и это близоруко: мне действительно все равно, КАК реализован хороший XPath / XSLT для Python и / или для Java, пока я использую это. (Определенные библиотеки могут облегчить миграцию существующего кода, но это менее важно, чем возможность выполнять такие задачи, как «быстрое применение преобразования XSLT» НЕКОТОРЫМ способом! -). Я знаю, что у меня возникла бы такая проблема, если бы она была хорошо сформулирована (особенно независимо от языка).

И последнее, но не менее важное: помните, что у вас может быть другая версия вашего приложения (с использованием одного и того же хранилища данных), некоторые из которых реализованы с помощью среды выполнения Python, другие - с средой выполнения Java, и вы можете получить доступ к версиям, отличным от & quot; default / активный & Quot; один с явными URL. Таким образом, вы могли бы иметь оба Pythonand Код Java (в разных версиях вашего приложения) использует и изменяет одно и то же хранилище данных, предоставляя вам еще большую гибкость (хотя только у одного будет такой «красивый» URL, как foobar.appspot.com - что, вероятно, важно только для доступ интерактивных пользователей в браузерах, я думаю ;-).

 14 апр. 2010 г., 11:26
Есть пижама (pyjs.org) как Pythonic альтернатива GWT - он возьмет код Python и скомпилирует его в Javascript, так же, как GWT делает для кода Java.
 19 сент. 2014 г., 21:06
Просто, чтобы дать "5 лет спустя" перспектива. Как Java-разработчик, я чувствую, что GAE использует устаревший стек. Не найдешьJava 8 support, (they are running Java 6 а также старый контейнер Jetty 6 сServlet API 2.5), в целом поддержка Java в GAE все еще застряла в 2010 году. Хотя я люблю простоту GAE и Google Powerful Services, я не могу рекомендовать GAE для Java, пока они не обновят свой стек.
 06 июл. 2009 г., 20:56
GWT - это в первую очередь технология на стороне клиента - вы можете использовать ее независимо от того, является ли ваш сервер Python или Java. Вы теряете немного синтаксического сахара из-за необходимости делать rpc поверх JSON, а не встроенного в RPC GWT, но если вы ненавидите JS и используете python, это все равно стоит посмотреть :)

Ваш ответ на вопрос