А>Планируем разработку достаточно большой и нагруженной системы
Имея такие планы — задавать вопросы "Никак не можем выбрать платформу" на форуме?

А>Кто имеет опыт работы с указанными технологиями — поделитесь, плиз, впечатлениями
А какой опыт имеет команда? Или она имеет сверхспособности к обучению?

Но если чуть серьезней, в гугле можно немало найти.

N.B.
Обычно для проекта: "web, большие распределенные бд, реально много пользователей" все заканчивается полуначатым проектом на PHP.

Здравствуйте, st.tyk, Вы писали:

ST>P.S. Уже нашел 2 компании, которые в свое время перешли с python на java:
ST>здесь и здесь
ST>Обсуждение перехода по Nuxeo: здесь

Добрый день. Не знаю насколько актуальным будет мой ответ.
Во-первых, хотелось бы выразить свои сомнения по поводу целесообразности перехода naumen'а на Java — год назад доводилось сталкиваться с их софтом для телефонии и возникло впечатление, что платные решеня хуже астериски в умелых руках, немного знающих Python. Я не думаю, что дело было в последнем, скорее в рках разработчиков. Ну это мое не совсем обьективное ИМХО.
А насчет Nuxeo сказать ничего конкретного не могу, но список клиентов внушительный. Тут удивляться думаю особо нечему — корпоративный буржусйкий рынок привык к решениям за миллионы долларов (а так оно и получается с Oracle и кучей другого софта, обычно используемого в таких проектах). Лично я сомневаюсь, что это именно то, чего вы хотели. Да и если разребаться со всем этим добром не знаю предметной области, то времени уйдет море. Ресурсов кстати такие приложения тоже требуют море, и при неумелом использовании ни о каких perfomance and scalability речи идти не может. Пример из жизни: знакомый, работающий в NetCracker сказал, что как-то неудачо "настроили-развернули" и сервачек восьмиядерный с 16 Гб оперативочки с сервером приложений умирал без видимых причин, и долго проблему найти не удавалось.
Что до выбора платформы, нужно быть очень осторожным и "быть в теме", для правильного выбора. Например, крупнейший сервис микроблоггинга в Азии (в Европе и США не настолько популярен) Plurk.com использует для отдачи основного контента Python через асинхронных сервер Tornado проксируемый и балансируемый с помощью nginx, а до недавнего времени для реализации Comet-соединений использовали Java (конкретно JBoss Netty), но перебрались на Node.js. Хотя тот же Tornado используется для обработки асинхронных запросов в FriendFeed (и был ими для этого написан). Да и немало высоконагруженных проектов крутятся на Python. Например, Google его использует довольно часто.
Как можно увидеть выбор весьма неоднозначен. С одной стороны Java, как классический язык с большим ворохом Enterprise технологий, но требующий огромных знаний и больших трудозатрат на изучение и во время разработки и развертывания (в случае, если это все добро использовать, хотя обо всем и речи быть не может ). С другой стороны гибкий, простой Python с кучей приятных и удобных плюшек, очень выразительный, довольно краткий, имеющий много библиотек, однако далеких от стандарта корпоративных. Последнее тоже двояко — никаких стандартов и спецификаций, ерализации всего-всего, но зато часто гораздо проще использовать. Например, я предпочел чей-то самописный примитивненький Redis-коннектор, расфуфыреному JRedis — нет необходимости тратить время на копании в javadoc и примерах, чтобs положить/получить данные, что мне и было нужно (создал экземпляр класса, вызвал метод, получил результат, весь код коннектора в одном файле, вместо иерархии классов распиханых по нескольким субпакетам). Зато в JRedis есть и какие-то возможности по асинхронной работе, и все-все, чего не откопать ни в какой из виденых мной библиотек для работы с этим хранилищем.
Исходя из всего вышесказанного склоняюсь к мысли, что Java — Enterprise стандарт. Если Вам нужно именно что-то такое корпоративно ориентированное, с очень-очень большими обьемами данных, поступающих ихх разных источников в разных форматах, с делающимися по этим данным отчетам, то Вам скорее всего сюда, только перед началом использования стоит почитать об инструментарии используемом для данных целей. Кстати, стоит обратить внимание и на Groovy/Scala — так как это все таже Java, но динамическая, со всей вытекающей отсюда гибкостью и порой излишней свободой.
Сам я в поледнее время все больше сижу на Python (чаще всего Django, хотя раньше активно использовал Java, а потом долгое время сидел с php из-за большого количества вакансий), так как занимаюсь все больше "Web2.0-проектами". Если Вы планируете создать какой-то динамичный интернет-ресурс, с высокой нагрузкой, богатыми возмодностями в кратчайшие сроки, то я думаю стоит обратить внимание именно на этот набор технологий. Кстати, Python сообщество для работы с зависимостями, пакетами, деплоингом приложений давно уже изобрело массу интрументов. Для начала хватит разобраться с virtualenv, setuptools и distribute, а довески подбирать по вкусу уже, если понадобится. Только подозреваю, что со списком языков программирования, с которыми ваша команда работала, мне кажется что придется довольно серьезнол омать стериотипы. Но это может быть и на пользу

Здравствуйте, Skynin, Вы писали:

S>N.B.
S>Обычно для проекта: "web, большие распределенные бд, реально много пользователей" все заканчивается полуначатым проектом на PHP.

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

S>>Имея такие планы — задавать вопросы "Никак не можем выбрать платформу" на форуме?
А>А Вы работаете все время над одной программой на одной платформе?
Не только я, а большинство профессиональных программистов.
Поди найди программиста который пишет то под JBoss то под Jetty, то под Glassfish. А надо, с такой же легкостью напишет довеску на ASP.NET к SharePoint.

Или, эту неделю под Rails, а следующую под Django.

S>>А какой опыт имеет команда? Или она имеет сверхспособности к обучению?
А>Если конкретно по языкам, то: C, C++, Delphi, C#, FoxPro, TSql, PlSql, VB...
С таким списком резюме можно не рассматривать Разве что если нужен Junior

Или это столько человек в команде, с такими знаниями?

А>Последний проект — в основном С#, в зависимости от квалификации осваивается от 2-х недель до 2-х месяцев
Да ну?

А>Найти можно много чего, а хочется услышать мнение людей, которые ИМЕЮТ ОПЫТ и могут рассказать о граблях, хотя бы в какой стороне их больше.
Грабли есть везде.
Но в зависимости от квалификации исправляются любые от 2-х недель до 2-х месяцев

А>Пути господни неисповедимы...

Вы бы конкретней описали проект.
А также — приемлемые сроки, исходя из бюджета, размер команды, РЕАЛЬНЫЙ ОПЫТ команды, и/или участников.
Что уже выбрано, не ЯП, а какие инструменты, фреймворки, сервера.
И в цифрах — пользователей ожидается -сколько. Количество коннектов в секунду — сколько. Размер данных, их сложность, упорядоченность/связность. Требуемое время отклика, отношение чтение/запись для основных сценариев, ..., ...

А>Зачем Вам конкретные цифры?
А>Вопрос то заключается именно в выборе языка и методологии...
Для — чего? С какой — целью?

"высоконагруженное веб приложение" это — "у меня где-то что-то иногда болит. Что посоветуете?"

Из неупомянутых мной вопросов, на которые тоже нужно перед выбором "языка и методологии" дать ответ:
А насколько сложная будет интерфейсная часть? Насколько сложны будут связи состояния интерфейса с общим состоянием системы?

И кажется Вы не поняли, язык программирования — это вообще не вопрос. Если, конечно Вы не решили все писать с нуля.
Более корректно ставить вопрос — а вот для реализации таких-то и таких-то требований — какие библиотеки, фреймворки, сервера, инструменты предпочительны исходя из вот такого списка требований, и после этого вопрос — а предложенные ... как легко интегрируются в единый комплекс — "высоконагруженное веб приложение"?

А может вначале вообще сделать побыстрее — прототипное решение из "пенопласта" а не ваять сразу стратосферную ракету?

Из того что Вы рассказали, — ничего не понятно и неизвестно.

"- Сейчас выпишем какое-нибудь лекарство, будете как-нибудь принимать и все пройдет" только и остается ответ.

Hi all!
Планируем разработку достаточно большой и нагруженной системы (web, большие распределенные бд, реально много пользователей). Никак не можем выбрать платформу: плюсы и минусы примерно знаем, предварительно остановились на Java, но что-то сомнения терзают
Кто имеет опыт работы с указанными технологиями — поделитесь, плиз, впечатлениями

Здравствуйте, Skynin, Вы писали:

S>Имея такие планы — задавать вопросы "Никак не можем выбрать платформу" на форуме?
А Вы работаете все время над одной программой на одной платформе?

S>А какой опыт имеет команда? Или она имеет сверхспособности к обучению?
Опыт большой, но все больше по технологиям microsoft. Если конкретно по языкам, то: C, C++, Delphi, C#, FoxPro, TSql, PlSql, VB...
Последний проект — в основном С#, в зависимости от квалификации осваивается от 2-х недель до 2-х месяцев

S>Но если чуть серьезней, в гугле можно немало найти.
Найти можно много чего, а хочется услышать мнение людей, которые ИМЕЮТ ОПЫТ и могут рассказать о граблях, хотя бы в какой стороне их больше.

S>Обычно для проекта: "web, большие распределенные бд, реально много пользователей" все заканчивается полуначатым проектом на PHP.
Пути господни неисповедимы...

А почему только три эти технологии? Почему не .Net, например?

Здравствуйте, Аноним, Вы писали:

А>Hi all!
А>Планируем разработку достаточно большой и нагруженной системы (). Никак не можем выбрать платформу: плюсы и минусы примерно знаем, предварительно остановились на Java, но что-то сомнения терзают

м.б. erlang/otp, раз "web, большие распределенные бд, реально много пользователей"?

Здравствуйте, Skynin, Вы писали:

Утверждения насчет "Не только я, а большинство профессиональных программистов" и "С таким списком резюме можно не рассматривать" — не серьезно: я привел знания команды, а не одного чела; то, что приходится часто переключаться — факт (сопровождается/дорабатывается старый софт + разрабатывается новый) и народу приходится работать то с фоксом, то с шарпом, то с делфи...

S>Вы бы конкретней описали проект.
S>А также — приемлемые сроки, исходя из бюджета, размер команды, РЕАЛЬНЫЙ ОПЫТ команды, и/или участников.
S>Что уже выбрано, не ЯП, а какие инструменты, фреймворки, сервера.
S>И в цифрах — пользователей ожидается -сколько. Количество коннектов в секунду — сколько. Размер данных, их сложность, упорядоченность/связность. Требуемое время отклика, отношение чтение/запись для основных сценариев, ..., ...

Зачем Вам конкретные цифры? Если в вопросе упомянуты 3 языка, значит для них будет предоставлена среда и компоненты....
Вопрос то заключается именно в выборе языка и методологии...

Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>А почему только три эти технологии? Почему не .Net, например?

Ограничения — только Linux, даже без mono

PS Это я открыл тему — только что зарегистрировался )

Здравствуйте, Wolverrum, Вы писали:

W>Здравствуйте, Аноним, Вы писали:

А>>Hi all!
А>>Планируем разработку достаточно большой и нагруженной системы (). Никак не можем выбрать платформу: плюсы и минусы примерно знаем, предварительно остановились на Java, но что-то сомнения терзают

W>м.б. erlang/otp, раз "web, большие распределенные бд, реально много пользователей"?

Да, какие-то части, скорее всего, будут на erlang, но их будет не много — только там, где "уткнемся".

Здравствуйте, Аноним, Вы писали:

А>Планируем разработку достаточно большой и нагруженной системы (web, большие распределенные бд, реально много пользователей). Никак не можем выбрать платформу: плюсы и минусы примерно знаем, предварительно остановились на Java, но что-то сомнения терзают
А>Кто имеет опыт работы с указанными технологиями — поделитесь, плиз, впечатлениями

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

Здравствуйте, Аноним, Вы писали:

А>Hi all!
А> предварительно остановились на Java, но что-то сомнения терзают

Какие именно сомнения?

Здравствуйте, Аноним, Вы писали:

Выбор очень простой.
Если цель — успешно реализовать проект, то пишите на том, что лучше всего знаете.
Если цель — изучить что-нибудь новенькое, то выбирайте то, что больше интересует.

Здравствуйте, LeonidV, Вы писали:

LV>Здравствуйте, Аноним, Вы писали:

А>>Hi all!
А>> предварительно остановились на Java, но что-то сомнения терзают

LV>Какие именно сомнения?

1. Модульность: у явы решается через OSGI, в питоне/руби (насколько я понял) — почти никак (т.е. каталоги/файлы — руками, как отслеживать зависимости при сотнях модулей?)
2. Поддержка: по моему субъективному мнению поддержка проектов на яве должна быть немного полегче... ошибаюсь?
3. Сервера приложений: о времени запуска jBoss уже чуть ли не легенды ходят; Pylons, Django и Zope вроде этим не страдают?
4. Наличие готовых решений, компонентов и пр. в яве гораздо больше (кстати богатство выбора порождает его сложность ); поддержка явы такими гигантами как Oracle, IBM...
5. Переход на динамический язык не всеми разработчиками хорошо воспринимается: ломаются стереотипы, мышление...

P.S. Уже нашел 2 компании, которые в свое время перешли с python на java:
здесь и здесь
Обсуждение перехода по Nuxeo: здесь

Вообще, я имел ввиду сомнения почему не Java. Не совсем понял, на это вы ответили или нет. Тем не менее.

ST>1. Модульность: у явы решается через OSGI, в питоне/руби (насколько я понял) — почти никак (т.е. каталоги/файлы — руками, как отслеживать зависимости при сотнях модулей?)
Смотря что под модулями понимать. Если просто зависимости, тут скорее maven в Java.

ST>2. Поддержка: по моему субъективному мнению поддержка проектов на яве должна быть немного полегче... ошибаюсь?
Поддежка на Java однозначно будет проще. Это одно из преимуществ весьма ограниченного языка — чем более язык содержит в себе синтаксического сахара, тем проще на нем разрабатывать и сложнее поддерживать код. В случе Ruby, например, лучше сразу запретить использование конструкций типа unless и ряда других.

ST>3. Сервера приложений: о времени запуска jBoss уже чуть ли не легенды ходят; Pylons, Django и Zope вроде этим не страдают?
Я не очень знаком с Python'ом, но мне всегда казалось что Django это web-фреймворк. Сравнивать его с JBoss (сервер приложений) не корректно. По поводу долгого старта — это важно при разработке, есть JRebel. А в production — ну загрузиться от в течение пары минут. Ну и что.

ST>4. Наличие готовых решений, компонентов и пр. в яве гораздо больше (кстати богатство выбора порождает его сложность ); поддержка явы такими гигантами как Oracle, IBM...
Да. Коммерческую поддержку можно взять практически для любого mainstream решения.

Здравствуйте, LeonidV, Вы писали:

ST>>1. Модульность: у явы решается через OSGI, в питоне/руби (насколько я понял) — почти никак (т.е. каталоги/файлы — руками, как отслеживать зависимости при сотнях модулей?)
LV>Смотря что под модулями понимать. Если просто зависимости, тут скорее maven в Java.
Не только зависимости: по-моему кроме как через OSGI нет способа обновить приложение (или часть) без перезапуска сервиса.

ST>>2. Поддержка: по моему субъективному мнению поддержка проектов на яве должна быть немного полегче... ошибаюсь?
LV>Поддежка на Java однозначно будет проще. Это одно из преимуществ весьма ограниченного языка — чем более язык содержит в себе синтаксического сахара, тем проще на нем разрабатывать и сложнее поддерживать код. В случе Ruby, например, лучше сразу запретить использование конструкций типа unless и ряда других.
Ruby уже выбыл из списка

ST>>3. Сервера приложений: о времени запуска jBoss уже чуть ли не легенды ходят; Pylons, Django и Zope вроде этим не страдают?
LV>Я не очень знаком с Python'ом, но мне всегда казалось что Django это web-фреймворк. Сравнивать его с JBoss (сервер приложений) не корректно. По поводу долгого старта — это важно при разработке, есть JRebel. А в production — ну загрузиться от в течение пары минут. Ну и что.
Согласен, сравнение не корректное. Лучше так: java сервера требуют больше ресурсов, их сложнее заставить работать "on demand", т.е. сервер долго запускается и быстро работает, загружая систему даже при минимальном количестве обращений. В случае с python по-моему можно держать загруженными только работающие компоненты.

ST>>4. Наличие готовых решений, компонентов и пр. в яве гораздо больше (кстати богатство выбора порождает его сложность ); поддержка явы такими гигантами как Oracle, IBM...
LV>Да. Коммерческую поддержку можно взять практически для любого mainstream решения.
Вот и вопрос: что "мейнстримнее" — java или python?

Здравствуйте, st.tyk, Вы писали:

ST>Не только зависимости: по-моему кроме как через OSGI нет способа обновить приложение (или часть) без перезапуска сервиса.
Ну, на самом деле можно и без OSGI обойтись, а по факту — да, это хороший вариант.

ST>Согласен, сравнение не корректное. Лучше так: java сервера требуют больше ресурсов, их сложнее заставить работать "on demand", т.е. сервер долго запускается и быстро работает, загружая систему даже при минимальном количестве обращений. В случае с python по-моему можно держать загруженными только работающие компоненты.
Так, а вы уверены что вам именно application server нужен, а не контейнер сервлетов? Tomcat на обычных приложениях загружается пару секунд. А еще есть Jetty и Resin.

Я не уверен, что на python есть аналог сервера приложений. Так что возможно вы не докнца разбираетесь в технологиях Java. Посмотрите внимательней чем AS от контейнера сервлетов отличается.

Здравствуйте, LeonidV, Вы писали:

LV>Здравствуйте, st.tyk, Вы писали:

ST>>Не только зависимости: по-моему кроме как через OSGI нет способа обновить приложение (или часть) без перезапуска сервиса.
LV>Ну, на самом деле можно и без OSGI обойтись, а по факту — да, это хороший вариант.

ST>>Согласен, сравнение не корректное. Лучше так: java сервера требуют больше ресурсов, их сложнее заставить работать "on demand", т.е. сервер долго запускается и быстро работает, загружая систему даже при минимальном количестве обращений. В случае с python по-моему можно держать загруженными только работающие компоненты.
LV>Так, а вы уверены что вам именно application server нужен, а не контейнер сервлетов? Tomcat на обычных приложениях загружается пару секунд. А еще есть Jetty и Resin.

LV>Я не уверен, что на python есть аналог сервера приложений. Так что возможно вы не докнца разбираетесь в технологиях Java. Посмотрите внимательней чем AS от контейнера сервлетов отличается.
Все правильно, TomCat + нужные компоненты по вкусу, но эти компоненты должны быть запущены до обращения к ним (запускать можно по требованию. а вот с остановом — проблема...). Кстати так в основном и работают.
Как с питоном лучше работать -пока не знаю

Здравствуйте, LeonidV, Вы писали:

LV>Я не уверен, что на python есть аналог сервера приложений.

Zope

Здравствуйте, Аноним, Вы писали:

А>Добрый день. Не знаю насколько актуальным будет мой ответ.

Добрый день!

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

В конечном итоге остановились на Python + Django, по мере надобности будем подключать доп.средства.

Здравствуйте, st.tyk, Вы писали:

ST>Здравствуйте, Аноним, Вы писали:

А>>Добрый день. Не знаю насколько актуальным будет мой ответ.

ST>Добрый день!

ST>+100 за ответ, пришли к точно таким же выводам, с единственной поправкой — корпоративные стандарты — вещь относительная и особо заморачиваться на ней не стоит. Куда важнее внутренний стандарт — начиная от тех.процесса до рекомендаций по использованию паттернов/сторонних библиотек

ST>В конечном итоге остановились на Python + Django, по мере надобности будем подключать доп.средства.

Рад за Вас . Django хорошее решении. Лично по моим ощущениям и впечатлениям лучший фреймворк из всех, с которыми мне приходилось хоть немного работать (а сталкивался и Zend, Yui, CodeIgniter (для php), и с Rube on Rails и даже с монтром Spring). Есть у него и слабые стороны, но соотношение плюсов/минусов по-моему мнения является очень неплохим. И даже лучше с учетом того, что проект активно развивается и постепенно проблемы устраняются, а новые возможности добавляются.
ЖЕлаю Вам успешного выполнения проекта.

Здравствуйте, Аноним, Вы писали:
А>Добрый день. Не знаю насколько актуальным будет мой ответ.

Прочитав ваш ответ, у меня сложилось впечатление, что для "умелого использования" Java нужно быть большим специалистом. А для Питона вопросы HA&HL решаются с ходу без глубокого опыта...

Здравствуйте, LeonidV, Вы писали:

LV>Здравствуйте, Аноним, Вы писали:
А>>Добрый день. Не знаю насколько актуальным будет мой ответ.

LV>Прочитав ваш ответ, у меня сложилось впечатление, что для "умелого использования" Java нужно быть большим специалистом. А для Питона вопросы HA&HL решаются с ходу без глубокого опыта...

Выдержка из философии Python:
"# Красивое лучше, чем уродливое.
# Явное лучше, чем неявное.
# Простое лучше, чем сложное.
# Сложное лучше, чем запутанное."
Большинство инструментария языка придерживается этой философии, потому изучение и использование инструментарии зачастую более легкое, чем освоение и использование аналогмчного инструментария из языка Java. У меня нет опыта работы с Zope, потому не буду утверждать, что использование Zope будет проще, чем использование чего-то из мира Java. Но если сравнивать использование spring framework и того же django (оба — мейнстрим для своего языка), то второй явно дружественней и легок для пониамния.
Точно так же как и использование любого известного мне WSGI-сервера вызывает меньше вопросов чем использование Apache Tomcat или Jetty. Точно так же и с большинством библиотек: пару строчек на Питоне (и сама библиотека в пару-тройку файлов) и создание какого-то класса, с каким-то хитрым вызовом параметров, вызов нескольких методов с экзеплярами каких-то других классов в качестве параметров (после чтения обьемного javadoc, зато умеет кучу всего что мне в данный момень не нужно). Для сравнения Quick Start для http://pypi.python.org/pypi/pyredis/0.3 и http://code.google.com/p/jredis/wiki/JRedisQuickStart. Зато в JRedis есть и такая штука.

И тут дело доходит до High Load. Забываем обо всем что написано в предыдущем абзаце. Настройка любого сервера на high load, это не просто настройка сервера и развертывание на нем приложения. Здесь нужно знать и косяки и подводные камни.
Написание приложения состоит из предугадывания бутылочных горлышек и построения такой архитектуры, которая была б к ним устойчива, либо позволяла легко модифицировать отдельные элементы в процессе оптимизации и с той же легкостью добавлять новые слои, позитивно влияющие на общую производительность системы. Когда программист занимается кешированием данных для повышения производительности его волнует не количество символов кода, требуемое для того чтобы извлечь данные из кеша, а разработка адекватной "модели протухания данных в кеше" или иной механихм позволяющий отдавать актуальные данные с наибольшей скоростью. Если вернуться к тому же Redis'у, который очень быстр, то опять же нужно думать, а что туда ложить, потому-что это не реляционная БД и некоторых вещей там не сделать или же это будет далеко не быстрее чем в реляционных БД. И т.д. и т.п.

Думаю, что вышеперечисленное и так понятно. Делать ли из этого вывод, что Python требует меньше знаний и навыков для высоконагруженных проектов? Предлагаю каждому решить это для себя самостоятельно.
Тут даже скорость интерпретатора не играет решающую роль, хотя может оказаться что придется что-то переписать на C для Python В данный момент, я для решения подавляющего количества задач использую именно Python, поскольку его использование в связке с memcached и redis должно дать мне достаточный уровень производительности (сейчас порядка 1000+ req/sec на типичных страницах при concurrency до 1000 + двольно низкое потребление памяти, что при данном масштабе и сложности проекта меня вполне устраивает). В других обстоятельствах, при наличии хорошей команды я вполне возможно выбрал бы Java.

P.S.: мое мнение может быть очень предвзято хотя бы потому, что я с Python близко познакомился после длительного использования Java и php (была работа и скрепя зубами работалась), так что Python после последнего показался глотком свежей воды и может я вот так уже больше года под впечатлением... Но java все равно люблю