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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А почему только три эти технологии? Почему не .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

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

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

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

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

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

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

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

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

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

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