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