Выбор Java vs Python в Google App Engine

Ответ 1

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

Как все будет продолжаться, конечно, трудно предсказать - спрос, вероятно, сильнее на стороне Java (тем более, что речь идет не только о Java, но и о других языках, расположенных на вершине JVM, так что это путь к например, PHP или Ruby-код в App Engine); однако команда разработчиков приложений Python имеет то преимущество, что на борту Guido van Rossum, изобретателя Python и удивительно сильного инженера.

С точки зрения гибкости, движок Java, как уже упоминалось, предлагает возможность запуска байт-кода JVM, созданного на разных языках, а не только Java - если вы находитесь в многоязычном магазине, который довольно большой. И наоборот, если вы ненавидите Javascript, но должны выполнить какой-то код в пользовательском браузере, Java GWT (генерирующий Javascript для вас из вашего кода на уровне Java) намного богаче и сложнее, чем альтернативы на основе Python (на практике, если вы выберете Python, вы будете писать JS самостоятельно для этой цели, тогда как если вы выберете Java GWT, это удобная альтернатива, если вы не будете писать JS).

В терминах библиотек это в значительной степени стирка - JVM достаточно ограничен (без потоков, без пользовательских загрузчиков классов, без JNI, без реляционной БД), чтобы препятствовать простому повторному использованию существующих библиотек Java столько же или более, чем существующие библиотеки Python также схожи с аналогичными ограничениями на время выполнения Python.

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

Ситуация XPath/XSLT (быть эвфемистичной...) не совсем идеальна с обеих сторон, вздох, хотя я думаю, что это может быть немного хуже в JVM (где, по-видимому, существенные подмножества саксонской сделанный для запуска, с некоторой осторожностью). Я думаю, что стоит открыть проблемы на странице

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

Ответ 2

Посмотрите это приложение для изменения производительности Python и Java:

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

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

Ответ 3

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

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

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

Ответ 4

Июнь 2013: Это видео является очень хорошим ответом инженером Google:

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

TL;DR;:

• Выберите язык, который вы и ваша команда наиболее продуктивны
• Если вы хотите построить что-то для производства: Java или Python (не Go)
• Если у вас есть большая команда и сложная база кода: Java (из-за статического анализа кода и рефакторинга)
• Небольшие команды, которые быстро повторяют: Python (хотя Java тоже в порядке)

Ответ 5

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

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

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

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

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

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

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

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

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

Ответ 6

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

• Производительность: Java потенциально быстрее, чем Python.
• Развитие Python находится под давлением отсутствия сторонних библиотек. Например, для Python/GAE вообще нет XSLT. Почти все библиотеки Python являются связями C (и они не поддерживаются GAE).
• API Memcache: Java SDK имеет более интересные возможности, чем SDK Python.
• API-интерфейс Datastore: JDO работает очень медленно, но собственный API-интерфейс хранилища данных очень быстрый и простой.

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

Ответ 7

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

EDIT: Я вижу, что вы нашли такой список

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

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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

Ответ 15

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

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

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

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

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

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