Выбор Java или Python в Google App Engine
https://stackoverflow.com/questions/1085898
-
23-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
В настоящее время Google App Engine поддерживает как Python, так и Java.Поддержка Java менее развита.Однако Java, похоже, имеет более длинный список библиотек и особенно поддерживает байт-код Java независимо от языков, используемых для написания этого кода.Какой язык обеспечит лучшую производительность и большую мощность?Пожалуйста, порекомендуйте.Спасибо!
Редактировать: http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1
Редактировать:Под «мощностью» я подразумеваю лучшую расширяемость и включение доступных библиотек за пределами фреймворка.Однако Python допускает только чистые библиотеки Python.
Решение
Я предвзят (будучи экспертом по 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, что, вероятно, важно только для доступа). Я полагаю, интерактивными пользователями в браузерах ;-).
Другие советы
Посмотрите это приложение, чтобы узнать об изменениях в производительности Python и Java:
http://gaejava.appspot.com/(редактировать:извините, ссылка сейчас не работает.Но следующий пункт все еще применялся, когда я видел его в последний раз)
В настоящее время Python и использование низкоуровневого API в Java работают быстрее, чем JDO на Java. для этого простого теста.По крайней мере, если базовый движок изменится, это приложение должно отразить изменения в производительности.
Основываясь на опыте запуска этих виртуальных машин на других платформах, я бы сказал, что вы, вероятно, получите более высокую производительность от Java, чем от Python.Однако не стоит недооценивать преимущества Python:Язык Python гораздо более продуктивен с точки зрения количества строк кода — по общему мнению, Python требует трети кода эквивалентной программы Java, оставаясь при этом таким же или более читаемым.Это преимущество умножается на возможность немедленного запуска кода без явного этапа компиляции.
Что касается доступных библиотек, вы обнаружите, что большая часть обширной библиотеки времени выполнения Python работает «из коробки» (как и Java).Популярный веб-фреймворк Django (http://www.djangoproject.com/) также поддерживается в AppEngine.
Что касается «мощности», трудно понять, что вы имеете в виду, но Python используется во многих различных областях, особенно в Интернете:YouTube написан на Python, как и Sourceforge (по состоянию на прошлую неделю).
Июнь 2013: Это видео — очень хороший ответ инженера Google:
http://www.youtube.com/watch?v=tLriM2krw2E
TLDR;является:
- Выберите язык, на котором вы и ваша команда наиболее продуктивны.
- Если вы хотите построить что-то для производства:Java или Python (не Go)
- Если у вас большая команда и сложная база кода:Java (из-за статического анализа кода и рефакторинга)
- Небольшие команды, которые быстро выполняют итерации:Python (хотя Java тоже подойдет)
Важный вопрос, который следует учитывать при выборе между Python и Java: как вы будете использовать хранилище данных на каждом языке (и большинство других аспектов исходного вопроса уже достаточно хорошо рассмотрены в этой теме).
Для Java, стандартным методом является использование JDO или JPA.Они отлично подходят для переносимости, но не очень хорошо подходят для хранилища данных.
Доступен низкоуровневый API, но это слишком низкий уровень для повседневного использования — он больше подходит для создания сторонних библиотек.
Для Python существует API, разработанный специально для предоставления приложениям простого, но мощного доступа к хранилищу данных.Он великолепен, за исключением того, что он не портативен и блокирует вас в GAE.
К счастью, разрабатываются решения для устранения недостатков, перечисленных для обоих языков.
Для Java, низкоуровневый API используется для разработки библиотек персистентности, которые гораздо лучше подходят для хранилища данных, чем JDO/JPA (IMO).Примеры включают Сиенский проект, и Объективизировать.
Недавно я начал использовать Objectify и считаю, что он очень прост в использовании и хорошо подходит для хранилища данных, а его растущая популярность привела к хорошей поддержке.Например, Objectify официально поддерживается новым сервисом Cloud Endpoints от Google.С другой стороны, Objectify работает только с хранилищем данных, тогда как Siena «вдохновлена» хранилищем данных, но предназначена для работы с различными базами данных как SQL, так и хранилищами данных NoSQL.
Для Python, предпринимаются усилия, чтобы разрешить использование API хранилища данных Python GAE вне GAE.Одним из примеров является серверная часть SQLite, которую Google выпустила для использования с SDK, но я сомневаюсь, что они собираются превратить ее в нечто готовое к производству.А ТайфунAE проект, вероятно, имеет больший потенциал, но я не думаю, что он еще готов к производству (поправьте меня, если я ошибаюсь).
Если у кого-то есть опыт использования какой-либо из этих альтернатив или он знает другие, добавьте их в комментарий.Лично мне очень нравится хранилище данных GAE — я считаю, что оно значительно лучше AWS SimpleDB, поэтому я желаю успеха этим усилиям по устранению некоторых проблем, связанных с его использованием.
Я настоятельно рекомендую Java для GAE, и вот почему:
- Производительность:Java потенциально быстрее Python.
- Разработка Python испытывает трудности из-за нехватки сторонних библиотек.Например, для Python/GAE вообще не существует XSLT.Почти все библиотеки Python являются привязками C (и они не поддерживаются GAE).
- API памяти кэша:Java SDK обладает более интересными возможностями, чем Python SDK.
- API хранилища данных:JDO очень медленный, но собственный API хранилища данных Java очень быстрый и простой.
Сейчас я использую Java/GAE в разработке.
Как вы уже заметили, использование JVM не ограничивает вас использованием языка Java.Список языков JVM и ссылки можно найти. здесь. Однако, Google App Engine ограничивает набор классов, которые вы можете использовать из обычного набора Java SE, и вам необходимо выяснить, можно ли использовать какую-либо из этих реализаций в механизме приложения.
РЕДАКТИРОВАТЬ:Я вижу, ты нашел такой список
Я не могу комментировать производительность Python.Однако JVM является очень мощной платформой с точки зрения производительности, учитывая ее способность динамически компилировать и оптимизировать код во время выполнения.
В конечном итоге производительность будет зависеть от того, что делает ваше приложение и как вы его кодируете.Ввиду отсутствия дополнительной информации, я думаю, невозможно дать больше указаний в этой области.
Я был поражен тем, насколько чистым, простым и свободным от проблем является Python/Django SDK.Однако я начал сталкиваться с ситуациями, когда мне нужно было начать больше использовать JavaScript, и я подумал, что, возможно, мне захочется воспользоваться GWT и другими утилитами Java.Я прошёл только половину руководства по GAE Java, и у меня возникала одна проблема за другой:Проблемы конфигурации Eclipse, версионность JRE, умопомрачительная сложность Java и запутанное и, возможно, неработающее руководство.Просмотр этого сайта и других ссылок отсюда убедил меня в этом.Я возвращаюсь к Python и рассмотрю Pyjamas, чтобы помочь мне с проблемами JavaScript.
Я немного опоздал к разговору, но вот мои два цента.Мне действительно было сложно выбирать между Python и Java, так как я хорошо разбираюсь в обоих языках.Как мы все знаем, у обоих есть свои преимущества и недостатки, и вы должны учитывать свои требования и платформы, которые лучше всего подходят для вашего проекта.
Как я обычно делаю в подобных дилеммах, я ищу цифры, подтверждающие мое решение.Я решил использовать Python по многим причинам, но в моем случае переломным моментом стал один сюжет.Если вы ищете «Google App Engine» в GitHub по состоянию на Сентябрь 2014 г., вы найдете следующий рисунок:
В этих цифрах может быть много ошибок, но в целом репозиториев GAE Python в три раза больше, чем репозиториев GAE Java.Более того, если вы перечислите проекты по «количеству звезд», вы увидите, что большинство проектов Python появляются вверху (вы должны принять во внимание, что Python существует дольше).На мой взгляд, это веский аргумент в пользу Python, поскольку я принимаю во внимание принятие и поддержку сообщества, документацию и доступность проектов с открытым исходным кодом.
Это хороший вопрос, и я думаю, что многие ответы дали хорошее представление о плюсах и минусах по обе стороны баррикад.Я пробовал AppEngine на базе Python и JVM (в моем случае я использовал Гаэлык это платформа приложений Groovy, созданная для AppEngine).Когда дело доходит до производительности на платформе, я не учел одну вещь, пока она не увидела меня в лицо, — это последствия «запросов загрузки», которые происходят на стороне Java.При использовании Groovy эти запросы на загрузку просто убийственны.
Написал пост на эту тему(http://distractable.net/coding/google-appengine-java-vs-python- Performance-comparison/), и я надеюсь найти способ обойти эту проблему, но если нет, я думаю, что вернусь к комбинации Python + Django, пока холодный запуск Java-запросов не окажет меньшего влияния.
Основываясь на том, как часто я слышу, как люди, использующие Java, жалуются на AppEngine по сравнению с пользователями Python, я бы сказал, что использование Python гораздо менее стрессово.
Еще есть проект Ненагруженная ласточка, который, очевидно, финансируется Google, если не принадлежит Google.Они пытаются реализовать серверную часть на основе LLVM для байт-кода Python 2.6.1, чтобы можно было использовать JIT и различные приятные оптимизации собственного кода/GC/многоядерных вычислений.(Отлично сказано:«Мы стремимся не делать оригинальных разработок, а использовать как можно больше результатов последних 30 лет исследований».) Они ищут пятикратное ускорение CPython.
Конечно, это не отвечает на ваш непосредственный вопрос, но указывает на «ликвидацию разрыва» (если таковой будет) в будущем (надеюсь).
Прелесть современного Python в том, насколько хорошо он взаимодействует с другими языками.Например, вы можете использовать как Python, так и Java в одной таблице с Jython.Конечно, jython, хотя и полностью поддерживает библиотеки Java, не поддерживает полностью библиотеки Python.Но это идеальное решение, если вы хотите возиться с библиотеками Java.Он даже позволяет смешивать его с кодом Java без дополнительного кодирования.
Но даже сам Python сделал некоторые шаги вперед.См., например, ctypes, около скорости C, прямой доступ к библиотекам C, и все это, не выходя из комфортного программирования на Python.Cython делает еще один шаг вперед, позволяя легко смешивать код C с кодом Python, или даже если вы не хотите возиться с C или C ++, вы все равно можете кодировать на Python, но использовать переменные статического типа, что делает ваши программы Python такими же быстрыми, как приложения C. .Кстати, Cython используется и поддерживается Google.
Вчера я даже нашел инструменты для Python для встраивания C или даже Ассамблеи (см. CorePy), мощнее этого не найти.
Python, безусловно, очень зрелый язык, не только стоящий сам по себе, но и способный легко взаимодействовать с любым другим языком.Я думаю, именно это делает Python идеальным решением даже в очень сложных и требовательных сценариях.
С помощью Python вы можете получить доступ к C/C++, Java, .NET и многим другим библиотекам практически без дополнительного кодирования, что дает вам также язык, который минимизирует, упрощает и украшает кодирование.Это очень заманчивый язык.
Ушел с Python, хотя GWT, кажется, идеально подходит для того типа приложения, которое я разрабатываю.JPA довольно запутан в GAE (например.нет @Embeddable и других непонятных недокументированных ограничений).Потратив неделю, я могу сказать, что Java на данный момент не совсем подходит для GAE.
Следует принять во внимание фреймворки, которые вы собираетесь использовать.Не все платформы на стороне Java хорошо подходят для приложений, работающих на App Engine, который несколько отличается от традиционных серверов приложений Java.
Следует учитывать время запуска приложения.С традиционными веб-приложениями Java вам не нужно об этом думать.Приложение запускается, а затем просто работает.Не имеет значения, занимает ли запуск 5 секунд или пару минут.При использовании App Engine вы можете оказаться в ситуации, когда приложение запускается только при поступлении запроса.Это означает, что пользователь ждет, пока загрузится ваше приложение.Здесь помогут новые функции GAE, такие как зарезервированные экземпляры, но сначала проверьте.
Другое дело — различные ограничения GAE на Java.Не все платформы довольны ограничениями на то, какие классы вы можете использовать, или тем фактом, что потоки не разрешены, или вы не можете получить доступ к локальной файловой системе.Эти проблемы, вероятно, легко обнаружить, просто погуглив о совместимости GAE.
Я также видел, как некоторые люди жаловались на проблемы с размером сеанса в современных UI-фреймворках (а именно в Wicket).В целом эти фреймворки склонны идти на определенные компромиссы, чтобы сделать разработку интересной, быстрой и простой.Иногда это может привести к конфликтам с ограничениями App Engine.
Первоначально я начал разработку GAE с использованием Java, но по этим причинам затем переключился на Python.Мой личное чувство заключается в том, что Python — лучший выбор для разработки App Engine.Я думаю, что Java более «дома», например, на Amazon Elastic Beanstalk.
НО с App Engine ситуация меняется очень быстро.GAE меняется сам по себе, и по мере того, как он становится все более популярным, инфраструктура также меняется, чтобы обойти его ограничения.
