Выбор Java по сравнению с Python на Google App Engine
var = raw_input("Please enter something: ")
print "you entered", var
Или для Python 3:
var = input("Please enter something: ")
print("You entered: " + var)
12 ответов
Я предвзято (являюсь экспертом по 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.
Что касается производительности, Я думаю, что это промывание, хотя вы должны тестировать свои собственные задачи - не полагайтесь на производительность высокооптимизированных JIT-реализаций JVM, не учитывая их большое время запуска и объем памяти, потому что среда движка приложения сильно отличается ( Затраты на запуск будут оплачиваться часто, поскольку экземпляры вашего приложения запускаются, останавливаются, перемещаются на другие хосты и т. д., и все это очевидно для вас - такие события обычно намного дешевле в средах выполнения Python, чем в JVM).
XPath Ситуация / XSLT (эвфемистически ...) не совсем идеальна с обеих сторон, вздох, хотя я думаю, что она может быть немного менее плохой в JVM (где, по-видимому, можно заставить работать значительные подмножества Saxon с некоторая осторожность). Я думаю это' Стоит открывать вопросы на странице Appengine Issues с XPath и XSLT в их заголовках - прямо сейчас есть только проблемы, требующие конкретных библиотек, и это близоруко: мне все равно, КАК хороший XPath / XSLT реализован для Python и / или для Java, если я могу его использовать. (Конкретные библиотеки могут облегчить миграцию существующего кода, но это менее важно, чем возможность выполнять такие задачи, как «быстрое применение XSLT-преобразования» НЕКОТОРЫМ способом! -). Я знаю, что я бы отметил такую проблему, если бы ее хорошо сформулировали (особенно независимо от языка).
И последнее, но не менее важное: помните, что у вас может быть другая версия вашего приложения (с использованием того же хранилища данных), некоторые из которых реализован со средой выполнения Python, некоторые со средой выполнения Java, и вы можете получить доступ к версиям, которые отличаются от "
Как вы определили, использование JVM не ограничивает вас использованием языка Java. Список языков JVM и ссылки можно найти здесь . Однако Google App Engine действительно ограничивает набор классов, которые вы можете использовать из обычного набора Java SE, и вы захотите выяснить, можно ли использовать какие-либо из этих реализаций в движке приложения.
РЕДАКТИРОВАТЬ: Я вижу, вы нашли такой список
, я не могу комментировать производительность Python. Однако JVM - очень мощная платформа с точки зрения производительности, учитывая ее способность динамически компилировать и оптимизировать код во время выполнения.
В конечном итоге производительность будет зависеть от того, что делает ваше приложение и как вы его кодируете. В отсутствие дополнительной информации я думаю, что невозможно дать больше указателей в этой области.
Я настоятельно рекомендую Java для GAE, и вот почему:
- Производительность: Java потенциально быстрее Python.
- Разработка Python находится под давлением отсутствия сторонних библиотек. Например, для Python / GAE вообще нет XSLT. Почти все библиотеки Python являются привязками C (и они не поддерживаются GAE).
- Memcache API: Java SDK имеет более интересные возможности, чем Python SDK.
- Datastore API: JDO очень медленный, но собственный API хранилища данных Java очень быстро и легко.
Я использую Java / GAE в разработке прямо сейчас.
Основываясь на опыте использования этих виртуальных машин на других платформах, я могу сказать, что вы, вероятно, получите более чистую производительность от Java, чем от Python. Однако не стоит недооценивать преимущества Python: язык Python гораздо более продуктивен с точки зрения количества строк кода - общее согласие заключается в том, что Python требует треть кода эквивалентной программы Java, оставаясь при этом более читаемым. Это преимущество умножается на возможность запускать код немедленно без явного шага компиляции.
Что касается доступных библиотек, вы обнаружите, что большая часть обширной библиотеки времени выполнения Python работает из коробки (как и Java). Популярный веб-фреймворк Django ( http://www.djangoproject.com/ ) также поддерживается в AppEngine.
Что касается «мощности», то это
Также есть проект Unladen Swallow , который, очевидно, принадлежит Google - финансируется, если не принадлежит Google. Они пытаются реализовать бэкэнд на основе LLVM для байт-кода Python 2.6.1, чтобы они могли использовать JIT и различные приятные нативные коды / GC / многоядерные оптимизации. (Хорошая цитата: «Мы не стремимся делать оригинальную работу, а использовать как можно больше результатов последних 30 лет исследований»). Они ищут 5-кратное ускорение CPython.
Конечно, это не так ». Я отвечу на ваш непосредственный вопрос, но указывает на «сокращение разрыва» (если таковой будет) в будущем (надеюсь).
Ушли с Python, хотя GWT кажется идеально подходит для разрабатываемого мной приложения. JPA сильно запутался в GAE (например, нет @Embeddable и других неясных недокументированных ограничений). Проведя неделю, я могу сказать, что в настоящий момент Java не подходит для GAE.
Следите за изменениями в производительности Python и Java в этом приложении:
http://gaejava.appspot.com/ (править: извинения, ссылка сейчас не работает. Но следующий параграф все еще применяется, когда я видел его последним)
В настоящее время Python и использование низкоуровневого API в Java быстрее, чем JDO на Java, для этого простого тест . По крайней мере, если основной движок изменится, это приложение должно отражать изменения производительности.
Сегодняшний питон прекрасно взаимодействует с другими языками. Например, у вас могут быть как 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 и Java важно учитывать , как вы будете использовать хранилище данных на каждом языке (и в большинстве других углов к исходному вопросу уже достаточно хорошо освещены в этой теме).
Для Java стандартным методом является использование JDO или JPA. Они отлично подходят для переносимости, но не очень подходят для хранилища данных.
Доступен низкоуровневый API, но это слишком низкий уровень для повседневного использования - он больше подходит для создания сторонних библиотек.
Для Python существует API, специально разработанный для предоставления приложениям простого, но мощного доступа к хранилищу данных. Это здорово, за исключением того, что он не переносится, поэтому он блокирует вас в GAE.
К счастью, разрабатываются решения для устранения недостатков, перечисленных для обоих языков.
Для Java низкоуровневый API используется для разработки библиотек сохраняемости, которые гораздо лучше подходят для хранилища данных, чем JDO / JPA (IMO). Примеры включают проект Siena и Objectify .
Недавно я начал использовать Objectify и считаю, что он очень прост в использовании и хорошо подходит для хранилища данных, а его растущая популярность превратилась в хорошую поддержку. Например, Objectify официально поддерживается новой службой Google Cloud Endpoints. С другой стороны, Objectify работает только с хранилищем данных, в то время как Siena «вдохновлена» хранилищем данных, но предназначена для работы с различными базами данных SQL и хранилищами данных NoSQL.
Для Python предпринимаются попытки разрешить использование API хранилища данных Python GAE вне GAE. Одним из примеров является бэкэнд SQLite, который Google выпустил для использования с SDK, но я сомневаюсь, что они намерены превратить его в нечто готовое к производству. Проект TyphoonAE , вероятно, имеет больший потенциал, но я не думаю, что он еще готов к производству (поправьте меня, если я ошибаюсь).
Если кто-то имеет опыт работы с какой-либо из этих альтернатив или знает о других, пожалуйста, добавьте их в комментарий. Лично мне очень нравится хранилище данных GAE - я считаю его значительным улучшением по сравнению с AWS SimpleDB - поэтому я желаю успеха этим усилиям по устранению некоторых проблем при его использовании.
Это хороший вопрос, и я думаю, что многие ответы дают хорошее представление о плюсах и минусах по обе стороны забора. Я пробовал как Python, так и AppEngine на основе JVM (в моем случае я использовал Gaelyk , который представляет собой среду приложений Groovy, созданную для AppEngine). Когда дело доходит до производительности на платформе, одна вещь, которую я не рассматривал, пока она не смотрела мне в лицо, - это последствия «запросов загрузки», которые происходят со стороны Java. При использовании Groovy эти запросы на загрузку просто убийственные.
Я написал сообщение по теме ( http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/ ) и надеюсь найти способ решения проблемы, но если нет, думаю, я вернусь к комбинации Python + Django, пока холодный запуск java-запросов не окажет меньшего влияния.
Основываясь на том, как много я слышу жалоб Java-людей на AppEngine по сравнению с пользователями Python, я бы сказал, что Python гораздо менее напряжен в использовании.
Я был поражен тем, насколько чистым, простым и беспроблемным является Python / Django SDK. Однако я начал сталкиваться с ситуациями, когда мне нужно было начать больше заниматься JavaScript, и я подумал, что, возможно, захочу воспользоваться преимуществами GWT и других утилит Java. Я прошел половину руководства по GAE Java, и у меня возникала одна проблема за другой: проблемы с конфигурацией Eclipse, версиониты JRE, ошеломляющая сложность Java и запутанное и, возможно, неверное руководство. Проверка этого сайта и других, на которые есть ссылки, решила для меня это. Я вернусь к Python и изучу Pyjamas, чтобы решить мои проблемы с JavaScript.