Здравствуйте, 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, а довески подбирать по вкусу уже, если понадобится. Только подозреваю, что со списком языков программирования, с которыми ваша команда работала, мне кажется что придется довольно серьезнол омать стериотипы. Но это может быть и на пользу

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

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

Добрый день!

+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 все равно люблю