Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
Я сам явист, в качестве бефитов явы в данном контексте, я вижу следуюшее:
1. Развитая система билда (maven, gradle) с поддержкой зависимостей, модулей и т.д.
2. Реально много библиотек и фреймворков. Надо встроить вебсервер — не проблема, надо математическую билиотечку, тоже пожалуйста, надо какой-нить complex event processing — все есть и т.д.
3. Хорошая совместимость с БД, мессаджингом и т.д. Драйвера есть для всех известных мне продуктов.
4. Легко (это все кончено относительно) интегрирутеся со всем чем угодно, есть JNI, можно в пол-тычка сделать rest-сервис и т.д.
5. Есть очень хорошая среда разработки (IntelliJ), которая легко работает (рефакторинг, поиск и т.д.) с проектами в десятки тысяч файлов.
6. У меня лично есть опыт как это все делается на Java. Насколько реально человеку "со стороны" сделать такое на C++?
Здравствуйте, StanislavK, Вы писали:
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
Из этих двух однозначно Java. Скорость компиляции, инструменты, возможность посадить за проект пачку студентов, дать им писать как попало в течении нескольких лет, несколько раз сменить состав и все равно получить продукт, который хоть и дико тормозит, постоянно плюется трейсами в лог, но как-то работает — это круто. На С++ такой проект с таким подходом падал бы не поднимаясь.
SK>1. Развитая система билда (maven, gradle) с поддержкой зависимостей, модулей и т.д.
В С++ такого нет.
SK>2. Реально много библиотек и фреймворков. Надо встроить вебсервер — не проблема, надо математическую билиотечку, тоже пожалуйста, надо какой-нить complex event processing — все есть и т.д.
Библиотек навалом, но как и в Java — горы известной субстанции, надо фильтровать. Еще неприятный момент — отсутствие в С++ единого style guide, через это выглядит код использующий несколько библиотек неряшливо.
SK>3. Хорошая совместимость с БД, мессаджингом и т.д. Драйвера есть для всех известных мне продуктов.
Хотя ORM-ы есть, но до реализаций JPA не дотягивают. В плане тестирования БД Java тоже дико заруливает.
SK>4. Легко (это все кончено относительно) интегрирутеся со всем чем угодно, есть JNI, можно в пол-тычка сделать rest-сервис и т.д.
Тут все нормально.
SK>5. Есть очень хорошая среда разработки (IntelliJ), которая легко работает (рефакторинг, поиск и т.д.) с проектами в десятки тысяч файлов.
Такого уровня IDE нет, рефакторинг, навигация, поиск — это боль. В качестве примера, в С++ чтобы найти нужный класс до сих пор рулит grep.
SK>6. У меня лично есть опыт как это все делается на Java. Насколько реально человеку "со стороны" сделать такое на C++?
Сделать на С++ реально все. Вопрос в том нужно ли? Конкретно для твоих задач, думаю — нет.
Здравствуйте, StanislavK, Вы писали:
SK>6. У меня лично есть опыт как это все делается на Java. Насколько реально человеку "со стороны" сделать такое на C++?
SK>Подскажите как там у С++ в этом плане.
Я сам в основном использую С++ и сейчас занимаюсь клиентами, но работал с С++, Ява, Шарпом и Руби на серверах.
Если не рассматривать финансовый вопрос, то для меня №1 однозначно идёт шарп.
Если нужно деньги считать — Ява, или Руби, по мне так не существенно.
С++ для каких-то производительных компонентов системы, при острой необходимости. В тех вариантах в которых я его использовал это было легаси, которое лучше было бы переписать на яву или шарп.
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
Руби, конечно. Странные у вас вопросы. Неужели кто-то ещё пишет на голой Яве???
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
Однозначно Java.
SK>Я сам явист, в качестве бефитов явы в данном контексте, я вижу следуюшее: SK>1. Развитая система билда (maven, gradle) с поддержкой зависимостей, модулей и т.д.
В C++ ничего из этого нет от слова совсем. Подключение любой библиотеки — это событие, которое нужно отмечать. Очень много геморроя если решение одновременно должно работать на разных платформах. То что во всяких убунтах apt-get install блаблабла и можно работать, в Windows будет список со ссылками что откуда качать и как ставить. После установки нужно пойти в билд-скрипты и прописать нужные пути. Всегда большой шанс, что о чём-то забыли и с первой попытки не заработает.
SK>2. Реально много библиотек и фреймворков. Надо встроить вебсервер — не проблема, надо математическую билиотечку, тоже пожалуйста, надо какой-нить complex event processing — все есть и т.д.
В C++ с этим опять же всё очень плохо. Тривиальные задачи типа прочитать/записать XML или какой-то другой JSON превращаются в кучу работы, с тоннами рукописного кода и кучей возможностей понаделать ошибок. Через пару дней такой работы возникает сильное желание больше никогда не трогать этот код, потому что от такой рутины чувствуешь себя грузчиком, а не программистом. Если в проекте есть коллеги, которые пишут на ЯП с динамической типизацией или рефлексией (типа разрабатывают другие компоненты), можно очень легко поругаться на почве отсутствия рефлексии и всех инструментов, завязанных на неё. Ещё бывают "сеньоры", которые хорошо знают C++, и вместо решения непосредственной задачи начинают велосипедить фреймворк для сериализации. Самый лучший и правильный. На шаблонах. Хороший, расширяемый. Т.к. буст не хочется тянуть, попутно пишут ещё пару велосипедов. Ну а если не сеньор, бывает забавно смотреть на всякие "<name>" + name + "</name>" с комментариями автора "это быстро работает", "зачем переусложнять". В итоге автор через пару месяцев начинает рассказывать, что правки очень сложно вносить, потому что код получился дурацкий.
Там где в Java не задумываясь подключаешь любимую библиотеку, замечательно решающую задачу, в C++ принято изобретать свой велосипед и отстаивать корректность такого решения до последнего.
SK>3. Хорошая совместимость с БД, мессаджингом и т.д. Драйвера есть для всех известных мне продуктов.
В C++ какбэ тоже это всё есть в большинстве случаев, но с теми же БД придётся работать без всяких JDBC и прочих JPA. Будет некий "альтернативный" интерфейс.
SK>4. Легко (это все кончено относительно) интегрирутеся со всем чем угодно, есть JNI, можно в пол-тычка сделать rest-сервис и т.д.
.so, написанно на C++ по-моему можно использовать из абсолютно любого ЯП — начиная со всяких Java и .NET, заканчивая Python, Ruby, Node и наверное какими-то ещё.
REST сервис — нет, это уже будет подвиг. Там где у Java программиста в резюме мелкими буквами написано "а ещё CXF", у C++ программиста будет на полстраницы "жирным таймз нью роман четырнадцатым" название библиотеки, с которой он про-бался месяц, но таки собрал её и заставил отдавать JSON. Без кеширования, без аутентификации, без сессий, но хоть как-то. Потому что это неподъёмная задача.
SK>5. Есть очень хорошая среда разработки (IntelliJ), которая легко работает (рефакторинг, поиск и т.д.) с проектами в десятки тысяч файлов.
Всё очень плохо т.к. нет "понятия модулей" и сам язык очень накрученный. Сколько помню — что NetBeans, что Eclipse, что Visual Studio всегда начинали капитально факапить, когда накрутишь пару шаблонов. Недавно появилась IDE от JetBrains, есть надежда, что через пару лет будет работать Даже если на IDE забить, читать ошибки компиляции C++ без подготовки будет очень нелегко, т.к. та же "пара шаблонов" разворачивается в "свыше 9000" строчек ошибок. Про рефакторинг даже не думайте — далеко не во всех ситуациях в принципе возможно понять какие действия должны быть доступны и собственно что вообще пытается сделать программист. Максимум какой-нибудь Rename будет работать. Всякие extract method — уже под вопросом.
SK>6. У меня лично есть опыт как это все делается на Java. Насколько реально человеку "со стороны" сделать такое на C++?
Вообще не реально. Даже не пытайтесь. Уровень перформанса работы, который достигается за 1 год на Java субъективно будет соответствовать 3 годам капитального задроства на C++. В жизни не видел ни одного C++ программиста, у которого бы на все "типичные" задачи были готовые решения. Причин вижу несколько:
1. C++ сам по себе намного сложнее Java — чтобы с ним ознакомиться в должной мере нужна куча времени
2. Как следствие из п.1., у C++ программистов очень часто встаёт вопрос — "как лучше сделать", потому что реально в языке много разных способов сделать одно и то же.
3. На C++ в принципе никто не решает задачи, которые вы описали, отсюда замкнутый круг: никому это нафиг не нужно, никто это не изучает, никто не умеет, но никому это и не нужно нафиг, ...
SK>Подскажите как там у С++ в этом плане.
Написать можно и на том и на том. На Java дешевле написать в плане числа разработчиков и их квалификации. На C++ будет кушать значительно меньше памяти, будут значительно более предсказуемые задержки. При необходимости предел тюнинга производительности на C++ выше. На Java будет меньше сложных багов (порча памяти в одном месте, упали в другом месте).
В общем я бы сформулировал так. Если предполагается очень много серверов (десятки или даже сотни), имеет смысл рассматривать C++, чтобы сэкономить на железе. Если это 1-2 сервера, выгоднее сэкономить на зарплате.
Специальный случай — немасштабируемое горизонтально по каким-то причинам приложение. Начиная с какого-то момента апгрейд сервера будет всё дороже и дороже, вплоть до миллионов долларов за мейнфреймы. Тогда у C++ будет больший предел, хотя надо считать, нужен ли этот предел, скорее всего не нужен.
Средства сборки, библиотеки, IDE я не считаю за серьёзные преимущества. Это всё настраивается и работает в любой среде.
Здравствуйте, StanislavK, Вы писали:
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
Ну я как C++ разработчик с 15 летнем стажем сказал бы что описанные выше, особенно товарищем andyag, ужасы с действительностью мало что имеют общего, но брать для твоей задачи C++ я бы не стал. Если задачу никак не решить на Python (а наличие "многопоточную" на это однозначно намекает), то самым правильным выбором будет Java. Быстрее, проще, есть экспертиза.
SK>Подскажите как там у С++ в этом плане.
Если очень хочется сделать на C++, то 1) CMake, 2) BOOST + STL, может придется чутка погуглить, 3) тут не скажу, работал с базами из плюсов лет 12 назад, 4) угу, никаких проблем быть не должно, но и опыт именно в C++ разработки понадобится, 5) ну, такого ничего нет, хотя Vim + cscope всегда за глаза хватало (стиль разработки на C++ обычно сильно отличается от Java. у тебя не будет 1001 фабрики для генерации еще одной фабрики, которая вернет тебе объект с абстрактным интерфейсом, который будет генерировать ...), 6) не реально. лучше не берись, плакать будешь, кактус очень колючий.
Здравствуйте, kaa.python, Вы писали:
KP>Ну я как C++ разработчик с 15 летнем стажем сказал бы что описанные выше, особенно товарищем andyag, ужасы с действительностью мало что имеют общего, но брать для твоей задачи C++ я бы не стал.
Укажи пожалуйста самый неправильный ужас из тех, которые я описал.
Здравствуйте, andyag, Вы писали:
A>Господа минусующие и ставящие смайлики, не возьмётся ли кто-то написать комментарии типа "ты неправ по поводу XXX потому что YYY"?
Я оценки не ставил, но твоё сообщение не столько по делу, сколько обсирает сиплюсплюсников. Да именно людей, а не сам язык. Сдаётся мне, что в сообщении очень много личного, а не объективного. Возможно, что ты даже в предмете толком не разбираешься.
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
Много лет назад я заменил С++ на java как раз с этой целью и с тех пор ни разу не пожалел об этом. Последний проект как раз заключался в переписывании большой многопоточной и многокомпонентной системы с С++ на java, так что удалсь в очередной раз на наглядном примере увидеть, насколько подходит для этой задачи java и насколько не подходит С++.
SK>2. Реально много библиотек и фреймворков. Надо встроить вебсервер — не проблема, надо математическую билиотечку, тоже пожалуйста, надо какой-нить complex event processing — все есть и т.д.
Да, это повод порадоваться за java и... забыть о большинстве этих технологий (особенно тех, которые величают себя фреймворками). Я давно сделал простой вывод (который однако дался далеко не просто) — хочешь сделать надежно, предсказуемо и просто — определи задачи и цели, упрости их реализацию как можно сильнее, в том числе за счет ограничения используемых сторонних зависимостей.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, andyag, Вы писали:
A>Укажи пожалуйста самый неправильный ужас из тех, которые я описал.
1) Есть CMake. Да, не Maven, но не плох и много что умеет, включая выкачивание зависимостей из удаленных репозиториев;
2) Библиотеки, обычно, подключаются легко. а) установил библиотеку, б) добавил зависимость в CMake;
3) Какие у тебя проблемы с разбором JSON/XML? Все просто и легко разбирается, есть несколько решений на любой вкус (с DOM и потоковые);
4) Описываемые тобой C++ программисты вызывают некое недоумение. Если ты только с такими и работал, то почему у тебя были приведенные выше проблемы вроде очевидно.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, andyag, Вы писали:
A>>Укажи пожалуйста самый неправильный ужас из тех, которые я описал.
KP>1) Есть CMake. Да, не Maven, но не плох и много что умеет, включая выкачивание зависимостей из удаленных репозиториев;
Не работал с этим. Но если по удобству оно напоминает Autotools, то лучше бы его не было.
KP>3) Какие у тебя проблемы с разбором JSON/XML? Все просто и легко разбирается, есть несколько решений на любой вкус (с DOM и потоковые);
Распарсить хмл и собрать его из динамических нод — это совсем не то, что хочется в 21 веке. Как дело обстоит с сериализацией/десериализацией объектов с использованием метаданных (в xsd или непосредственно в классе), все также, как и 10 лет назад? Или таки что-то изменилось?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, andyag, Вы писали:
A>>Господа минусующие и ставящие смайлики, не возьмётся ли кто-то написать комментарии типа "ты неправ по поводу XXX потому что YYY"?
N>Я оценки не ставил, но твоё сообщение не столько по делу, сколько обсирает сиплюсплюсников. Да именно людей, а не сам язык.
Спасибо за ответ. Неприязнь к коммьюнити C++ есть, скрывать нечего. Вызвана неприязнь исключительно опытом общения с C++ программистами и сложностями, которые у них возникают на ровном месте. Речь ни в коем случае не про болтовню на RSDN, а про работу на работе. А язык в отрыве от коммьюнити рассматривать смысла нет.
N>Сдаётся мне, что в сообщении очень много личного, а не объективного.
Не, там всё более-менее объективно. По крайней мере все минусы, которые я описал, либо из практики либо из гуглинга. На C++ уже лет 7 не пишу, но насколько знаю, за это время ничего особо не изменилось. Выпустили новую ещё более страшную версию языка, в которой в очередной раз благополучно забили на модули. Про управление зависимостями по-прежнему никто не чешется. Вот она культура C++ — эти ребята просто не видят тех проблем в своём любимом ЯП и его экосистеме, которые видят коллеги, использующие другие ЯП.
N>Возможно, что ты даже в предмете толком не разбираешься.
Такое очень может быть. А ты в теме? Можешь указать на некорректные заявления? На самом деле буду очень благодарен, т.к. за поливание C++ грязью мне не платят, а если он лучше, чем мне кажется, очень круто было бы об этом знать.
Здравствуйте, kaa.python, Вы писали:
SK>>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали? KP>Ну я как C++ разработчик с 15 летнем стажем сказал бы что описанные выше, особенно товарищем andyag, ужасы с действительностью мало что имеют общего, но брать для твоей задачи C++ я бы не стал. Если задачу никак не решить на Python (а наличие "многопоточную" на это однозначно намекает), то самым правильным выбором будет Java. Быстрее, проще, есть экспертиза. SK>>Подскажите как там у С++ в этом плане. KP> 6) не реально. лучше не берись, плакать будешь, кактус очень колючий.
Понятно. Если честно, то наверно самый большой аргумет. Остальное, как я догадываюсь, больше дело опыта. Нам нужен достаточно бытстрый старт, что на С++, без надлежащего опыта, не реально. Думаю, что полетим на java и будем некоторые куски, по-надобности, приписывать на С++. Кстати, есть ли очевидные грабли в таком подходе?
Здравствуйте, StanislavK, Вы писали:
SK>Понятно. Если честно, то наверно самый большой аргумет. Остальное, как я догадываюсь, больше дело опыта. Нам нужен достаточно бытстрый старт, что на С++, без надлежащего опыта, не реально. Думаю, что полетим на java и будем некоторые куски, по-надобности, приписывать на С++. Кстати, есть ли очевидные грабли в таком подходе?
По моим ощущениям, JNI не самая интуитивно понятная штука. Поэтому, если с этой стороны подойдете, то либо заранее разберитесь с JNI, либо найдите человека которой в этой хреноте разбирается.
Здравствуйте, kaa.python, Вы писали:
KP>1) Есть CMake. Да, не Maven, но не плох и много что умеет, включая выкачивание зависимостей из удаленных репозиториев;
Давай расставим точки над i. CMake это самая лучшая система сборки в мире C++. Всё остальное хуже. Про самую лучшую систему сборки ты говоришь "неплох".
Из моего опыта с CMake — разные библиотеки подключаются немного по-разному. Это самое "немного" приводит к необходимости гуглить, а иногда даже задавать вопросы на форумах.
С Maven такого не бывает — с ним любая библиотека подключается одним и тем же способом — написанием 5 строчек. И сразу всё работает.
KP>2) Библиотеки, обычно, подключаются легко. а) установил библиотеку, б) добавил зависимость в CMake;
Про разницу в установке библиотек под Linux и Windows написал в оригинальном сообщении. Есть даже хороший пример — OpenSSL под Windows.
Про "добавил зависимость" написал немного выше.
KP>3) Какие у тебя проблемы с разбором JSON/XML? Все просто и легко разбирается, есть несколько решений на любой вкус (с DOM и потоковые);
Дело в том, что летом-осенью 2015 года никто в здравом уме не станет руками работать с DOM (и тем более стримом), когда задача заключается в "принять запрос" и "отдать ответ". Это только в C++ нужно написать руками какое-то UpdatePersonRequest::fromXML(string const& xml) и std::string PersonUpdatedResponse::toXml() const, больше такого нет нигде — этот код просто не пишут.
KP>4) Описываемые тобой C++ программисты вызывают некое недоумение. Если ты только с такими и работал, то почему у тебя были приведенные выше проблемы вроде очевидно.
Это замечательный ответ. Т.е. ты уверен, что если топикстартер вдруг решит таки использовать C++ вместо Java, ему обязательно попадутся хорошие коллеги, у которых не возникает сложностей со всем, что я описал? Или ты имеешь в виду, что статистически "хороших" больше, чем "плохих"?
Статистика, безусловно, такая статистика, но я не первый год программист, и не с одним C++ программистом общался — как со стороны коллег, так и со стороны инженеров на стороне клиентов.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, StanislavK, Вы писали:
SK>>Понятно. Если честно, то наверно самый большой аргумет. Остальное, как я догадываюсь, больше дело опыта. Нам нужен достаточно бытстрый старт, что на С++, без надлежащего опыта, не реально. Думаю, что полетим на java и будем некоторые куски, по-надобности, приписывать на С++. Кстати, есть ли очевидные грабли в таком подходе?
KP>По моим ощущениям, JNI не самая интуитивно понятная штука. Поэтому, если с этой стороны подойдете, то либо заранее разберитесь с JNI, либо найдите человека которой в этой хреноте разбирается.
Если нет причин использовать именно JNI, есть ещё JNA.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
Тот для которого больше всего готового есть. В общем, все зависит от характера системы и общих требований к ней.
SK>1. Развитая система билда (maven, gradle) с поддержкой зависимостей, модулей и т.д.
Билд систем завались, самая популярная — CMake, интегрирована в кучу разных IDE. Нормального управления зависимостями нет. Если работать в linux с нормальным менеджером пакетов, то это не проблема, делаешь apt-get install libxxx-dev, добавляешь в билд скрипт строчку и все. Как это сейчас делается под виндой я не знаю, думаю что как и раньше — через хитро вывернутую жопу.
SK>2. Реально много библиотек и фреймворков. Надо встроить вебсервер — не проблема, надо математическую билиотечку, тоже пожалуйста, надо какой-нить complex event processing — все есть и т.д.
Для С++ есть очень много всего. Помимо очевидных (Boost, Poco) есть куча всяких сишных библиотек, которые очень стабильны и очень даже юзабельны, например libapr. Веб сервер — не проблема, есть Си-шный libmicrohttpd, есть что-то на основе asio. Можно сделать плагин для nginx например (на java ты так не сделаешь).
SK>3. Хорошая совместимость с БД, мессаджингом и т.д. Драйвера есть для всех известных мне продуктов.
В той же APR есть драйвера для кучи разных СУБД. Обычно драйвера не проблема найти, так как разработчики всевозможных СУБД, как правило, в первую очередь выпускают драйвер для Си. Если нет враппера для С++ то его всегда легко написать, или юзать сишную версию напрямую. В общем, ни разу не встречал подобных проблем. Со всякими rabbit-ами та же история.
SK>4. Легко (это все кончено относительно) интегрирутеся со всем чем угодно, есть JNI, можно в пол-тычка сделать rest-сервис и т.д.
RESTful сервис можно легко сделать на чем угодно, лишь бы был http сервер встраиваемый. Интергрируется со всем чем угодно еще лучше джавы ибо С ABI поддерживается нативно, лучше интероперабельность только в Си.
SK>5. Есть очень хорошая среда разработки (IntelliJ), которая легко работает (рефакторинг, поиск и т.д.) с проектами в десятки тысяч файлов.
Тут есть целый зоопарк. Если нравится IntelliJ, то наверное понравится CLion, я предпочитаю QtCreator.
SK>6. У меня лично есть опыт как это все делается на Java. Насколько реально человеку "со стороны" сделать такое на C++?
Очень сложно взять и сходу начать писать хороший С++ код. Порог вхождения довольно высокий.
Здравствуйте, andyag, Вы писали:
A>Не, там всё более-менее объективно. По крайней мере все минусы, которые я описал, либо из практики либо из гуглинга. На C++ уже лет 7 не пишу, но насколько знаю, за это время ничего особо не изменилось. Выпустили новую ещё более страшную версию языка, в которой в очередной раз благополучно забили на модули. Про управление зависимостями по-прежнему никто не чешется. Вот она культура C++ — эти ребята просто не видят тех проблем в своём любимом ЯП и его экосистеме, которые видят коллеги, использующие другие ЯП.
У меня С++ работает исключительно в качестве инструмента для решения отдельных ресурсоёмких задач, чаще всего математического характера. Используются почти исключительно открытые библиотеки с исходниками. В результате есть много либо не связанных, либо слабо связанных между собой модулей. Поэтому:
1. Используемое мной подмножество языка не кажется сколько-то либо переусложнённым, я радуюсь выходу новых стандартов.
2. Экосистема = CMake + компилятор + чужие, чаще всего кроссплатформенные исходники, с которыми практически нет никаких проблем (ffmpeg, OpenCV, Qt, Caffe и т.д. и т.п.). Есть ещё проприетарные библиотеки и SDK от Интела, АМД, Нвидиа. С ними тоже более менее.
3. Простенький GUI для задач визуализации пишется на Qt — всё очень здорово и легко.
Самые большие проблемы связаны с поддержкой разных устройств и версий OpenCL/CUDA, но поверь мне, что в других языках проблем было бы намного больше или не было бы вообще возможности работать на данном оборудовании.
N>>Возможно, что ты даже в предмете толком не разбираешься. A>Такое очень может быть. А ты в теме? Можешь указать на некорректные заявления? На самом деле буду очень благодарен, т.к. за поливание C++ грязью мне не платят, а если он лучше, чем мне кажется, очень круто было бы об этом знать.
Если говорить об опыте написания больших многопоточных и распределённых систем на С++, то я не в теме. Для меня всё это разрабатывают ребята на чистом WinAPI, на Qt, boost. Всё работает, не падает, память не течёт. Были, например, системы безопасности, работающие годами без перезагрузок и общающиеся по сети и не только с кучами датчиков, устройств, видеокамер. Написано на плюсах, работало быстро, выжималось из железа всё. Даже драйвера для некоторых PCI и PCI-E плат видеозахвата писали сами (не я, у меня только математика). Данные в БД хранились. Это считается за велосипеды? Честно говоря, я не уверен, что можно было бы на той же Java написать эффективный сервер для видеонаблюдения, многие оптимизации там касались очень низкоуровневых вещей при работе с памятью. Например неплохой прирост в производительности давал следующий трюк: получаемые от ip-камер кадры для декодирования лучше записывать не просто в буфер, а делать в начале буфера небольшой случайного размера poadding, чтобы предсказатель переходов в процессоре вовремя сбрасывал кэш. Такие мелочи выясняются только при детальном анализе профайлера и я не уверен, что они возможны в случае использования той же Java.
Что лучше для топикстартера я не знаю, т.к. не в курсе его предметной области. На первый взгляд, с плюсами ему лучше не связываться. Тут ты прав, но выразил это совсем не в тех выражениях.
Здравствуйте, ELazin, Вы писали:
SK>>6. У меня лично есть опыт как это все делается на Java. Насколько реально человеку "со стороны" сделать такое на C++? EL>Очень сложно взять и сходу начать писать хороший С++ код. Порог вхождения довольно высокий.
Беспокоит не столько язык/код, сколько вся экосистема. Если начинаешь не правильно пользоваться тулзами, что-то не так организовывать, использовать "не те" библиотеки, потом очень трудно выкарабкаться.
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали? SK>Я сам явист, в качестве бефитов явы в данном контексте, я вижу следуюшее: SK>1. Развитая система билда (maven, gradle) с поддержкой зависимостей, модулей и т.д. SK>2. Реально много библиотек и фреймворков. Надо встроить вебсервер — не проблема, надо математическую билиотечку, тоже пожалуйста, надо какой-нить complex event processing — все есть и т.д. SK>3. Хорошая совместимость с БД, мессаджингом и т.д. Драйвера есть для всех известных мне продуктов. SK>4. Легко (это все кончено относительно) интегрирутеся со всем чем угодно, есть JNI, можно в пол-тычка сделать rest-сервис и т.д. SK>5. Есть очень хорошая среда разработки (IntelliJ), которая легко работает (рефакторинг, поиск и т.д.) с проектами в десятки тысяч файлов. SK>6. У меня лично есть опыт как это все делается на Java. Насколько реально человеку "со стороны" сделать такое на C++?
SK>Подскажите как там у С++ в этом плане.
Ни разу ни джавист, ни плюсовик, но выскажусь: если уж совсем жизненно важные требования к производительсноти (ну прям совсем-совсем) то плюсы, во всех остальных случаях ява.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, andyag, Вы писали:
A>>Не, там всё более-менее объективно. По крайней мере все минусы, которые я описал, либо из практики либо из гуглинга. На C++ уже лет 7 не пишу, но насколько знаю, за это время ничего особо не изменилось. Выпустили новую ещё более страшную версию языка, в которой в очередной раз благополучно забили на модули. Про управление зависимостями по-прежнему никто не чешется. Вот она культура C++ — эти ребята просто не видят тех проблем в своём любимом ЯП и его экосистеме, которые видят коллеги, использующие другие ЯП.
N>У меня С++ работает исключительно в качестве инструмента для решения отдельных ресурсоёмких задач, чаще всего математического характера. Используются почти исключительно открытые библиотеки с исходниками. В результате есть много либо не связанных, либо слабо связанных между собой модулей. Поэтому:
А для таких задач по-моему и нет альтернатив C++. Когда речь идёт про "вертикальный" перформанс, деньгя платятся не за скорость разработки, а за хороший результат.
В мире Java очень часто бывает наоборот — пусть оно работает в 10 раз меделенее чем могло бы на том же самом железе, но фичи должны делаться не за недели, а за часы.
N>>>Возможно, что ты даже в предмете толком не разбираешься. A>>Такое очень может быть. А ты в теме? Можешь указать на некорректные заявления? На самом деле буду очень благодарен, т.к. за поливание C++ грязью мне не платят, а если он лучше, чем мне кажется, очень круто было бы об этом знать.
N>Если говорить об опыте написания больших многопоточных и распределённых систем на С++, то я не в теме. Для меня всё это разрабатывают ребята на чистом WinAPI, на Qt, boost. Всё работает, не падает, память не течёт. Были, например, системы безопасности, работающие годами без перезагрузок и общающиеся по сети и не только с кучами датчиков, устройств, видеокамер. Написано на плюсах, работало быстро, выжималось из железа всё.
Оно в итоге масштабировалось горизонтально или всё-таки был некий центральный сервер, который просто очень быстро работает? Java в таких задачах предполагает именно горизонтальное масштабирование — один узел может быть и не потянет "много", но всегда есть возможность добавить ещё. Для построения такой архитектуры есть _много_ готовых инструментов.
N>Даже драйвера для некоторых PCI и PCI-E плат видеозахвата писали сами (не я, у меня только математика). Данные в БД хранились. Это считается за велосипеды? Честно говоря, я не уверен, что можно было бы на той же Java написать эффективный сервер для видеонаблюдения, многие оптимизации там касались очень низкоуровневых вещей при работе с памятью. Например неплохой прирост в производительности давал следующий трюк: получаемые от ip-камер кадры для декодирования лучше записывать не просто в буфер, а делать в начале буфера небольшой случайного размера poadding, чтобы предсказатель переходов в процессоре вовремя сбрасывал кэш. Такие мелочи выясняются только при детальном анализе профайлера и я не уверен, что они возможны в случае использования той же Java.
Вы описываете специфические задачи, в которых много цифродробления и файн-тюнинга на низком уровне — здесь безусловно Java нечего делать. Но это не те задачи, решением которых занимается большинство. Большинство клепает нечто, что так или иначе попадает под определение "странички, формочки, бд". У меня сейчас проект, где фасадная часть написана на Java (типа REST API), а полезная функциональность на C++ (много всякой математики). От C++ команды каждый день нытьё на каждый чих по интеграции, т.к. многое из того, что на Java вообще не нужно писать у них разворачивается в сотни строк рукописного кода. Сотни строк кода, который нужно тестировать и сопровождать. Проекту чуть меньше года, C++ная часть рефакторингу _уже_ не поддаётся ("всё, легаси"), у них нет сил слезть с ручной сериализации и, например, генерировать нужный код из XSD или использовать что-то аналогичное. Почему — не очень интересно. Интересно, что в моей практике это не единичный случай.
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности. SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
На самом деле непонятно, зачем вообще разводить такую дискуссию не касаясь вопросов производительности...
Вот если бы вы включили в этот список "высокопроизводительную", то тогда c++ был бы фактически безальтернативным вариантом.
Ну а если это обычная good enough система, то зачем кто-то будет заморачиваться с написанием на нем всей системы? Будет вполне достаточно реализовать критические места — обработку мультимедиа, математику и т.п. Собственно в реальной жизни оно наверное так и делается.
SK>1. Развитая система билда (maven, gradle) с поддержкой зависимостей, модулей и т.д.
Средства сборки мало изменились с 80 годов, у иных проектов сборочные скрипты по сложности превосходят сам проект. Разве что теперь в этом процессе зачастую еще участвует IDE.
SK>2. Реально много библиотек и фреймворков. Надо встроить вебсервер — не проблема, надо математическую билиотечку, тоже пожалуйста, надо какой-нить complex event processing — все есть и т.д.
Фреймворков мало, библиотек много, но велосипедов (и допиленных под себя библиотек) — еще больше, ведь все хотят платить только за то, что используют.
SK>4. Легко (это все кончено относительно) интегрирутеся со всем чем угодно, есть JNI, можно в пол-тычка сделать rest-сервис и т.д.
Практически все что что угодно и так написано на C/C++ (включая реализации самой jvm, насколько я знаю) или, как минимум, неявно с ним интегрируется.
SK>5. Есть очень хорошая среда разработки (IntelliJ), которая легко работает (рефакторинг, поиск и т.д.) с проектами в десятки тысяч файлов.
С инструментами все весьма плохо, рефакторинга вменяемого нет, форматирования нет, проверок стиля нет (и самого стиля для проверки тоже нет). Все на плечах разработчиков.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>Здравствуйте, StanislavK, Вы писали:
VTT>На самом деле непонятно, зачем вообще разводить такую дискуссию не касаясь вопросов производительности... VTT>Вот если бы вы включили в этот список "высокопроизводительную", то тогда c++ был бы фактически безальтернативным вариантом. VTT>Ну а если это обычная good enough система, то зачем кто-то будет заморачиваться с написанием на нем всей системы? Будет вполне достаточно реализовать критические места — обработку мультимедиа, математику и т.п. Собственно в реальной жизни оно наверное так и делается.
Потому, что в плане производительность интриги нет. Все, что надо или и так понятно или достаточно "просто" измерить.
SK>Беспокоит не столько язык/код, сколько вся экосистема. Если начинаешь не правильно пользоваться тулзами, что-то не так организовывать, использовать "не те" библиотеки, потом очень трудно выкарабкаться.
VTT>Средства сборки мало изменились с 80 годов, у иных проектов сборочные скрипты по сложности превосходят сам проект. Разве что теперь в этом процессе зачастую еще участвует IDE.
Странно что-то подобное читать от С++ разработчика в 2015-м году
Ну вот как минимум есть http://bazel.io/
Еще есть CMake, qmake и много чего еще.
Здравствуйте, ELazin, Вы писали:
VTT>>Средства сборки мало изменились с 80 годов, у иных проектов сборочные скрипты по сложности превосходят сам проект. Разве что теперь в этом процессе зачастую еще участвует IDE.
EL>Странно что-то подобное читать от С++ разработчика в 2015-м году EL>Ну вот как минимум есть http://bazel.io/ EL>Еще есть CMake, qmake и много чего еще.
Странно, что в 2015 году по-прежнему приходится ковыряться со всякими *make.
Вроде как наметилась позитивная тенденция к приходу полноценных пакетных менеджеров (CPM, biicode и nuget), которые в теории позволяют собрать что-то без обычного лютого напряга с зависимостями. Но я думаю, что каких-то принципиальных изменений можно будет ожидать только когда (и если) устандартят c++ модули. А до тех пор придется мучится с perl-bash-awk-regex-python-autotools-bat-pws-*make-франкенштейнами.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, eugene0, Вы писали:
E>Посмотрел. Ставить джаву, чтобы собирать проекты на C++? Вот это поворот!
Людей, использующих Eclipse или NetBeans, это наверное не смущает.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, ELazin, Вы писали:
SK>>Беспокоит не столько язык/код, сколько вся экосистема. Если начинаешь не правильно пользоваться тулзами, что-то не так организовывать, использовать "не те" библиотеки, потом очень трудно выкарабкаться. EL>что значит "не те"?
Точно не скажу, но могу дать такой пример, недавно по несчастному стечению обстоятельств надо было сделать гуй на javascript. Наша команда на этом не специализируется, так, что быстренько погуглили и наваяли на jQuery. В целом промахнулись, так как jQuery замечательно только для части того, что нам было надо и сейчас уже приходится переписывать с AngularJS, которую опять же без опыта правильно использовать не просто и там в процессе тоже пару раз промахнулись. Трудно когда нет "ощющения" того, что правильно.
Здравствуйте, eugene0, Вы писали:
E>Здравствуйте, ELazin, Вы писали:
EL>>Ну вот как минимум есть http://bazel.io/ E>Посмотрел. Ставить джаву, чтобы собирать проекты на C++? Вот это поворот!
Чего уж там, берите сразу Gradle если Java не влом ставить. Оно замечательно умеет C++ билдить.
Здравствуйте, Nuzhny, Вы писали:
VTT>>Странно, что в 2015 году по-прежнему приходится ковыряться со всякими *make.
N>А не странно, что в 2015 приходится вручную писать код, набирая его на клавиатуре?
Здравствуйте, LaPerouse, Вы писали:
LP>Не работал с этим. Но если по удобству оно напоминает Autotools, то лучше бы его не было.
CMake генерирует проекты autotools под Линуксом и, вообще-то, он ужас-ужас-ужас, но обычно это совсем незаметно! Почему-то разработчики систем сборки всегда берут всё самое худшее из программирования. Когда это не программирование в XML, то обязательно свой сумасшедший динамический интерпретируемый язык с побочными эффектами, волшебными именами, глобальными переменными и printf отладкой.
Здравствуйте, StanislavK, Вы писали:
SK>6. У меня лично есть опыт как это все делается на Java. Насколько реально человеку "со стороны" сделать такое на C++?
Если "со стороны" — то реальность не ахти.
SK>Подскажите как там у С++ в этом плане.
С++ хорош там, где требуется микросекундный отклик или числодробление. Или там, где охота из имеющихся ресурсов выжать максимум эффективности (до 3-х раз в сравнении с джавой и дотнетом).
Современную сложную систему лучше всего делать гетерогенной — высокоуровневая логика + общение с БД на чем-то легко отлаживаемом, а обработка большого трафика данных — на С++. С математическими и сетевыми библиотеками в С++ хорошо.
VTT>Странно, что в 2015 году по-прежнему приходится ковыряться со всякими *make.
Что не так с этими *make кроме названия?
VTT>Вроде как наметилась позитивная тенденция к приходу полноценных пакетных менеджеров (CPM, biicode и nuget), которые в теории позволяют собрать что-то без обычного лютого напряга с зависимостями. Но я думаю, что каких-то принципиальных изменений можно будет ожидать только когда (и если) устандартят c++ модули. А до тех пор придется мучится с perl-bash-awk-regex-python-autotools-bat-pws-*make-франкенштейнами.
biicode недавно умер, nuget — windows only, CPM не знаю что такое. IMO все это не нужно если есть нормальный пакетный менеджер и какое-нибудь общее место для заголовочных файлов и библиотек (как /usr/include в linux). Управление зависимостями и сборка это разные вещи, не стоит все смешивать.
E>Посмотрел. Ставить джаву, чтобы собирать проекты на C++? Вот это поворот!
Ну то есть полностью воспроизводимые билды тебя не впечатлили совсем, зато зависимость от джавы сразу бросилась в глаза. Ясно-понятно.
Здравствуйте, ELazin, Вы писали:
EL>biicode недавно умер, nuget — windows only, CPM не знаю что такое. IMO все это не нужно если есть нормальный пакетный менеджер и какое-нибудь общее место для заголовочных файлов и библиотек (как /usr/include в linux). Управление зависимостями и сборка это разные вещи, не стоит все смешивать.
А у тебя не бывает разных версий библиотеки на разных проектах? Пакетные менеджеры позволяют такое?
Здравствуйте, ELazin, Вы писали:
EL>Что не так с этими *make кроме названия?
Выше уже несколько раз об этом писали.
EL>IMO все это не нужно если есть нормальный пакетный менеджер
и если есть добрый дядя, подготовивший подходящий для конкретной системы пакет EL>какое-нибудь общее место для заголовочных файлов и библиотек (как /usr/include в linux)
*тут шутка про размазывание ровным слоем*
EL>Управление зависимостями и сборка это разные вещи, не стоит все смешивать.
Вообще-то второе не имеет смысла без первого.
Более того, в этом плане у c/c++ имеется фундаментальная проблема:
В самом языке средств для полного описания прямых и косвенные зависимостей нет, а жесткая привязка к файловой системе есть. Информация о зависимостях (как минимум об их части) и о привязке в файловой системе необходима для осуществления сборки и поэтому присутствует в том или ином виде в сборочных скриптах, но извлечение ее из феерического винегрета этих скриптов обычно крайне затруднено. А перед тем, как приступать к сборке, эту информацию приходится собирать и готовить нужные зависимости. Причем практически всегда вручную. То есть у нас втройне убогая ситуация: одновременно и частичное дублирование информации, и неполнота информации, и необходимость ручных манипуляций.
По факту сборочные скрипты в их нынешнем виде(ах) — это "неуправление" зависимостями.
При наличии явного управления зависимостями роль сборочных скриптов заметно упрощается, вызвать исполняемый файл с несколькими аргументами — это дело техники.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
EL>>Что не так с этими *make кроме названия? VTT>Выше уже несколько раз об этом писали.
Ничего дельного там не написано об этом, ты просто уходишь от ответа на прямой вопрос. Вот что конкретно не так с CMake?
EL>>IMO все это не нужно если есть нормальный пакетный менеджер VTT>и если есть добрый дядя, подготовивший подходящий для конкретной системы пакет
Это же можно сказать про репозитории вроде maven-а. Если дядя подготовил то оно там есть, если не подготовил, то нет.
EL>>Управление зависимостями и сборка это разные вещи, не стоит все смешивать. VTT>Вообще-то второе не имеет смысла без первого. VTT>Более того, в этом плане у c/c++ имеется фундаментальная проблема:
Вообще, система управления зависимостями может быть одна для всех (system wide package manager), а не для каждого языка свой отдельный, как сейчас. Вот представь что у тебя есть питоновский пакет, который зависит от конкретной версии какого-нибудь модуля и еще один пакет, который зависит от другой версии того же модуля. Ты не сможешь установить две версии модуля сразу через pip, только используя virtualenv и два разных окружения, что не вариант, если пакеты должны использоваться совместно. Современный пакетный менеджер pip, лол.
В С++ я могу собрать что-угодно как угодно, немножко попрелюбодействовав с билд-скриптами.
VTT>В самом языке средств для полного описания прямых и косвенные зависимостей нет, а жесткая привязка к файловой системе есть. Информация о зависимостях (как минимум об их части) и о привязке в файловой системе необходима для осуществления сборки и поэтому присутствует в том или ином виде в сборочных скриптах, но извлечение ее из феерического винегрета этих скриптов обычно крайне затруднено. А перед тем, как приступать к сборке, эту информацию приходится собирать и готовить нужные зависимости. Причем практически всегда вручную. То есть у нас втройне убогая ситуация: одновременно и частичное дублирование информации, и неполнота информации, и необходимость ручных манипуляций.
Если библиотека установлена как положено, то никакой привязки к файловой системе как-бы и нет, оно все всегда сразу находится. CMake тоже не заставляет тебя напрямую работать с именами файлов, находишь зависимость через FIND_PACKAGE и потом просто используешь соответствующие переменные. Я ни разу не делал то, о чем ты тут пишешь "практически всегда вручную" вручную. Оно как-то само получалось
VTT>По факту сборочные скрипты в их нынешнем виде(ах) — это "неуправление" зависимостями.
Вот наверное поэтому они и называются "сборочными скриптами".
VTT>При наличии явного управления зависимостями роль сборочных скриптов заметно упрощается, вызвать исполняемый файл с несколькими аргументами — это дело техники.
Вот о чем я и говорю. Вот как это в винде делается — не знаю, может там все это имеет место быть.
Здравствуйте, ELazin, Вы писали:
EL>Вообще, система управления зависимостями может быть одна для всех (system wide package manager), а не для каждого языка свой отдельный, как сейчас. Вот представь что у тебя есть питоновский пакет, который зависит от конкретной версии какого-нибудь модуля и еще один пакет, который зависит от другой версии того же модуля. Ты не сможешь установить две версии модуля сразу через pip, только используя virtualenv и два разных окружения, что не вариант, если пакеты должны использоваться совместно. Современный пакетный менеджер pip, лол.
Это ж ограничение самого питона. Как ты в одном месте будешь использовать одну версию модуля, в другом (в пределах одной программы) — другую? Разве что дать им разные названия, но пользователи на такое могут быть не рассчитаны.
EL>В С++ я могу собрать что-угодно как угодно, немножко попрелюбодействовав с билд-скриптами.
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
...
для C++ со сложной структурой проекта и множеством подпроектов нужна быстрая распределенная система сборки на каждого разработчика. Если послушать местных "берем cmake, а там дальше разберемся", то лучше сразу не брать С++. Это как лакмусовая бумажка, если даже сборку проекта не могут сделать "многопоточную, многокомпонентную, распределенную ...", то проект посложнее и подавно.
Вообще с С++ главный риск это люди и опыт людей. По скольку никакой специфики проекта не известно, то можно предположить что железки и вендоры вас не ограничивают и на более простом инструменте напишете функционал быстрее, отладите быстрее, потюните быстрее. В общем оставьте с++ в покое =) разве что для чегото ресурсоемкого/низкоуровневого сделаете/возьмете (полу-)готовое, отдельный модуль.
Здравствуйте, Nuzhny, Вы писали:
N>Например неплохой прирост в производительности давал следующий трюк: получаемые от ip-камер кадры для декодирования лучше записывать не просто в буфер, а делать в начале буфера небольшой случайного размера poadding, чтобы предсказатель переходов в процессоре вовремя сбрасывал кэш.
Стесняюсь спросить, а зачем для производительности "вовремя сбрасывать кэш" и какое к этому отношение имеет предсказатель переходов?
EL>В С++ я могу собрать что-угодно как угодно, немножко попрелюбодействовав с билд-скриптами. EL>Если библиотека установлена как положено, то никакой привязки к файловой системе как-бы и нет, оно все всегда сразу находится. CMake тоже не заставляет тебя напрямую работать с именами файлов, находишь зависимость через FIND_PACKAGE и потом просто используешь соответствующие переменные. Я ни разу не делал то, о чем ты тут пишешь "практически всегда вручную" вручную. Оно как-то само получалось
Ну-ну, вот так в каждой библиотеке у разработчиков свое представление о том, как положено (и далеко не все удосуживаются поделиться этим представлением с другими). Когда скачущий в агонии по диску билд-скрипт отдает концы непонятно где и почему, то начинается многочасовое веселье с разгадыванием ребусов. Но даже когда он отрабатывает, то все равно стоит проверить, а то ли он намутил. Другими словами, нужно владеть ситуацией, знать что для чего задействуется и откуда именно должно браться. А выуживать эту информацию практически всегда приходится вручную (так или иначе).
EL>>>IMO все это не нужно если есть нормальный пакетный менеджер EL>Вообще, система управления зависимостями может быть одна для всех (system wide package manager), а не для каждого языка свой отдельный, как сейчас.
Для одно-то языка никак не могут нормально сделать, а вы хотите сразу для всех. Да еще system wide.
EL>Вот как это в винде делается — не знаю, может там все это имеет место быть.
У вас какая-то нездоровая неприязнь к ОС Windows. Так и до столменизма можно докатиться.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, Patalog, Вы писали:
P>Стесняюсь спросить, а зачем для производительности "вовремя сбрасывать кэш" и какое к этому отношение имеет предсказатель переходов?
Во времена Пентиумов 4 так работало: предсказатель видит, что адрес начала буфера "какой-то не такой" и вовремя реагировал на приход буфера с новым кадром. Профайлер показывал уменьшение "cache miss rate" или чего-то похожего. Скорость работы увеличивалась. Данный трюк был описан где-то у Агнера Фога.
CMake генерирует проекты autotools под Линуксом и, вообще-то, он ужас-ужас-ужас, но обычно это совсем незаметно!
Первое предложение, а уже булшит, CMake не умеет генерировать "проекты autotools" и никогда не умел, лол.
VTT>Ну-ну, вот так в каждой библиотеке у разработчиков свое представление о том, как положено (и далеко не все удосуживаются поделиться этим представлением с другими). Когда скачущий в агонии по диску билд-скрипт отдает концы непонятно где и почему, то начинается многочасовое веселье с разгадыванием ребусов. Но даже когда он отрабатывает, то все равно стоит проверить, а то ли он намутил. Другими словами, нужно владеть ситуацией, знать что для чего задействуется и откуда именно должно браться. А выуживать эту информацию практически всегда приходится вручную (так или иначе).
Ты излишне драматизируешь КМК, я такое ни разу не видел. Даже гребаный boost собирается как раз плюнуть.
EL>>>>IMO все это не нужно если есть нормальный пакетный менеджер EL>>Вообще, система управления зависимостями может быть одна для всех (system wide package manager), а не для каждого языка свой отдельный, как сейчас. VTT>Для одно-то языка никак не могут нормально сделать, а вы хотите сразу для всех. Да еще system wide.
Я имел ввиду пакетные менеджеры (что очевидно из более ранних комментариев). Вот скажем питоновский пакет я могу установить с помощью pip, а могу с помощью apt, а могу вообще через easy_install. Для питона наличие встроенных средств управления зависимостями оправдано тем, что он может использоваться там, где нет вообще никакого пакетного менеджера (windows) и все эти инструменты входят в дистрибутив питона и есть централизованный репозиторий, но вот для С и С++, лично я всегда предпочту apt всяким там biicode-ам, просто потому что многие зависимости нужно устанавливать и на клиентской машине, а это проще всего делать средствами системы (в отличии от питона, где иногда проще ставить средствами самого питона), packaging проще становится и все такое. Если же у меня есть зависимость от какой-нибудь библиотеки, которую я беру в сторонней системе управления зависимостями, то мне нужно будет вручную нарулить для нее пакет и поставлять его клиенту, может даже поднять свой репозиторий пакетов. Это лишний геморрой, так никто не делает (AFAIK).
EL>>Вот как это в винде делается — не знаю, может там все это имеет место быть. VTT>У вас какая-то нездоровая неприязнь к ОС Windows. Так и до столменизма можно докатиться.
Wishful thinking. Я ничего подобного не говорил, просто последний раз собирал что-то под windows больше пяти лет назад.
Здравствуйте, ELazin, Вы писали:
EL>CMake не умеет генерировать "проекты autotools" и никогда не умел, лол.
Возможно, пусть тогда делает make проекты, это не столь важно.
EL>Даже гребаный boost собирается как раз плюнуть.
Почему гребанный?
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
EL>>CMake не умеет генерировать "проекты autotools" и никогда не умел, лол. VTT>Возможно, пусть тогда делает make проекты, это не столь важно.
В действительности важно, т.к. эта генерация может быть скрыта под капотом и плюсовая IDE будер работать как бы с проектом на CMake безо всякой промежуточной генерации.
Да и вообще, CMake можно достаточно просто использовать для кросскомпиляции проектов подо всякие embedded платформы. Скажем, под sparc.
VTT>Возможно, пусть тогда делает make проекты, это не столь важно.
Ну а что в этом плохого? Я знаю как минимум 3 разные плюсовые IDE, которые используют CMake для сборки, генерируя make-файлы. И знаешь, очень удобно. Работать можно в CLion и потом тот же самый CMake проект, без модификаций, собирать на CI сервере через скрипт, тесты прогонять и даже пакеты собирать.
VTT>Почему гребанный?
Там своя система сборки и нужно сначала собрать bjam, а потом с его помощью уже собрать буст. Не самый приятный опыт.
Здравствуйте, ELazin, Вы писали:
VTT>>Почему гребанный? EL>Там своя система сборки и нужно сначала собрать bjam, а потом с его помощью уже собрать буст. Не самый приятный опыт.
Справедливости ради, в последних версиях (примерно как пару лет) появился скрипт bootstrap с которым все гораздо проще:
cd boost_some_version && ./bootstrap.sh && ./b2 <some_options> install
что впрочем не очень сильно отличается от старых версий, где надо было делать
Учитывая что ОС, базы, компиляторы, все самые высоконагруженные распределенные системы так или иначе написаны на C++ говорить о том java лучше как минимум смешно.
---SK>1. Развитая система билда (maven, gradle)
пару раз в неделю у нас падает билд от нарушений зависмостей (большая международная компаний с java ентерпрайс сервером).
Очень редко было в предидушей компании (большая международная компаний с C++ ентерпрайс сервером).
--SK>2. Реально много библиотек и фреймворков.
В С++ тоже вагон и тележка
В конце концов C++ живет на куда большем числе устройств чем Java.
SK>3. Хорошая совместимость с БД, мессаджингом и т.д. Драйвера есть для всех известных мне продуктов.
И как правило в одном количестве. Больше года ждали JDBC драйвер для MSSQL с поддержкой мирроринга.
А у C++: АДО, ODBC, OLEDB, .NET, ................
--можно в пол-тычка сделать rest-сервис
пункт 4 вообше мало понятен. что с чем интегрируется. Особенно с CUDA.
---SK>5.
Есть еше более замечательная система Visual Studio, где проекты в сотни тышь файлов прекрасно живут.
И каждый раз матерюсь перегружая Eclipse который течет и виснет на больших проектах и с которого уже не слезть.
---SK>6. У меня лично есть опыт как это все делается на Java.
У меня и там и там.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Patalog, Вы писали:
P>>Стесняюсь спросить, а зачем для производительности "вовремя сбрасывать кэш" и какое к этому отношение имеет предсказатель переходов?
N>Во времена Пентиумов 4 так работало: предсказатель видит, что адрес начала буфера "какой-то не такой" и вовремя реагировал на приход буфера с новым кадром. Профайлер показывал уменьшение "cache miss rate" или чего-то похожего. Скорость работы увеличивалась. Данный трюк был описан где-то у Агнера Фога.
А какой "предсказатель" имеется в виду? Branch predictor? Но при чем здесь тогда cache miss?
Здравствуйте, andyag, Вы писали:
A>.so, написанно на C++ по-моему можно использовать из абсолютно любого ЯП — начиная со всяких Java и .NET, заканчивая Python, Ruby, Node и наверное какими-то ещё. A>REST сервис — нет, это уже будет подвиг. Там где у Java программиста в резюме мелкими буквами написано "а ещё CXF", у C++ программиста будет на полстраницы "жирным таймз нью роман четырнадцатым" название библиотеки, с которой он про-бался месяц, но таки собрал её и заставил отдавать JSON. Без кеширования, без аутентификации, без сессий, но хоть как-то. Потому что это неподъёмная задача.
Враки. Делал такое лет 6-8 назад. Без кэширования ответов (ибо не надо было), с сессиями, аутентификацией и имперсонацией. Не сказал бы, что это было сильно сложно или объемно.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
V>С++ хорош там, где требуется микросекундный отклик или числодробление. Или там, где охота из имеющихся ресурсов выжать максимум эффективности (до 3-х раз в сравнении с джавой и дотнетом).
Вообще-то разница больше чем в 3 раза. Однажды скомпилировал функцию вычисления БПФ на Java и скорость оказалась
в 8 раз меньше, чем на C++.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
SK>Подскажите как там у С++ в этом плане.
У Java преимуществом является наличие большого количества фреймворков. Если они вам подходят, то на Java будет быстрее.
Вообще, если это вопрос разработки конкретной программы, то я бы рассмотрел конкретные требования к библиотекам и наличие соответсвтующих библиотек на C++.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, StanislavK, Вы писали:
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
Если выбирать из Java и C++, то правильный ответ, разумеется, Scala.
Здравствуйте, Poopy Joe, Вы писали:
PJ>Здравствуйте, StanislavK, Вы писали:
SK>>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
PJ>Если выбирать из Java и C++, то правильный ответ, разумеется, Scala.
Здравствуйте, iZEN, Вы писали:
PJ>>Если выбирать из Java и C++, то правильный ответ, разумеется, Scala. ZEN>Почему не Go и не Clojure?
Scala явистам будет привычнее, чем Clojure. Не такой культурный шок.
На счет Go ничего не знаю, то что я про него читал удивляет, что его вообще кто-то хочет использовать.
Здравствуйте, ELazin, Вы писали:
EL>Можно сделать плагин для nginx например (на java ты так не сделаешь).
На Java своих веб-серверов столько, что писать плагин под nginx нет никакой необходимости. Деплоймент приложения под какой-нибудь Томкат фактически и выглядит как подключение плагина.
Nginx как application server это сомнительная идея.
SK>>3. Хорошая совместимость с БД, мессаджингом и т.д. Драйвера есть для всех известных мне продуктов. EL>В той же APR есть драйвера для кучи разных СУБД. Обычно драйвера не проблема найти, так как разработчики всевозможных СУБД, как правило, в первую очередь выпускают драйвер для Си.
Под хорошей совместимостью с БД сейчас подразумеваются уже обычно не драйвера, а более высокоуровневые абстракции.
Здравствуйте, VTT, Вы писали:
VTT>На самом деле непонятно, зачем вообще разводить такую дискуссию не касаясь вопросов производительности... VTT>Вот если бы вы включили в этот список "высокопроизводительную", то тогда c++ был бы фактически безальтернативным вариантом.
Это не так. Выбор всегда строится на основе нескольких критериев — стоимость и время разработки, стоимость вычислительной операции, масштабируемость. По стоимости операции С++ выиграет, потому что код будет более эффективно использовать ресурсы, но по затратам на разработку этот проект на С++ может быть банально нереализуем, а Java по остальным критериям вполне впишется, потому что приемлемую производительность на ней вполне можно достичь, пусть, может быть, и с бОльшим железом.
Здравствуйте, Poopy Joe, Вы писали:
PJ>Если выбирать из Java и C++, то правильный ответ, разумеется, Scala.
Scala это С++ на JVM. И тут, мне кажется, лучше либо мух, либо котлеты...
V>>С++ хорош там, где требуется микросекундный отклик или числодробление. Или там, где охота из имеющихся ресурсов выжать максимум эффективности (до 3-х раз в сравнении с джавой и дотнетом).
lpd>Вообще-то разница больше чем в 3 раза. Однажды скомпилировал функцию вычисления БПФ на Java и скорость оказалась lpd>в 8 раз меньше, чем на C++.
Неплохо бы такие заявления подтверждать тестами. А то может в варианте жабы боксинг на анбоксинге и вызывается это безобразие из JNI. В любом случае в жаве сложнее контролировать ресурсы (время отклика), и печальней с библиотеками числодробилок- они все на C или Fortran. Но это решаемо. В C++ сложнее не портить память и это тоже решаемо.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Aртёмка, Вы писали:
Aё>>Неплохо бы такие заявления подтверждать тестами.
IID>Поддерживаю! А то может оказаться что не в 8 раз, а в 18, или даже в 80
Честно говоря вспоминаю, что разные компилеры java показывали тогда результаты, отличающиеся ровно в 2 раза, и я, вероятно, проводил тест БПФ на медленном.
Но вот ссылка на benchmark разных тестов:
Результаты: разница в 1-4 раза.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Nikе, Вы писали:
N>>>Если не рассматривать финансовый вопрос, то для меня №1 однозначно идёт шарп.
__S>>можешь раскрыть подробнее?
N>Линк + лучший уровень комфорта при работе в среде.
Здравствуйте, __SPIRIT__, Вы писали:
N>>>>Если не рассматривать финансовый вопрос, то для меня №1 однозначно идёт шарп.
__S>>>можешь раскрыть подробнее?
N>>Линк + лучший уровень комфорта при работе в среде.
__S>не точно спросил — получил кривой ответ
__S>Я имел ввиду почему шарп дорог?
Виндовские сервера + SQL Server не дорогое решение разве? Может быть я ошибаюсь.
Здравствуйте, MTD, Вы писали:
MTD>Такого уровня IDE нет, рефакторинг, навигация, поиск — это боль. В качестве примера, в С++ чтобы найти нужный класс до сих пор рулит grep.
Студия с ассистом смотрят на эти заявы с недоумением.
Здравствуйте, MTD, Вы писали:
SK>>1. Развитая система билда (maven, gradle) с поддержкой зависимостей, модулей и т.д. MTD>В С++ такого нет.
Чем cmake не угодил?
Здравствуйте, StanislavK, Вы писали:
SK>>>Беспокоит не столько язык/код, сколько вся экосистема. Если начинаешь не правильно пользоваться тулзами, что-то не так организовывать, использовать "не те" библиотеки, потом очень трудно выкарабкаться. EL>>что значит "не те"? SK>Точно не скажу, но могу дать такой пример, недавно по несчастному стечению обстоятельств надо было сделать гуй на javascript. Наша команда на этом не специализируется, так, что быстренько погуглили и наваяли на jQuery. В целом промахнулись, так как jQuery замечательно только для части того, что нам было надо и сейчас уже приходится переписывать с AngularJS, которую опять же без опыта правильно использовать не просто и там в процессе тоже пару раз промахнулись. Трудно когда нет "ощющения" того, что правильно.
Это называется "Отсутствие опыта" и язык\библиотеки тут как бы совершенно не при чём
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали? SK>Я сам явист
Используйте то, что знаете.
SK>Подскажите как там у С++.
Чем то напоминает кунг-фу: порог вхождения высокий, всё долго и дорого, у каждого оно лучше чем у других, но результаты восхитительны.
p.s. И детских бед с обработкой беззнаковых типов, не наблюдается :P
80% людей оценивают свое мастерство выше среднего...
2. Как следствие из п.1., у C++ программистов очень часто встаёт вопрос — "как лучше сделать", потому что реально в языке много разных способов сделать одно и то же.
я бы сделал разделение:
1) некоторый низкоуровневый движок, критичный к производительности и памяти, на C++
2) высокий уровень на Java, или чем-то подобном
НО, если Вы сами на C++ не писали хотя бы лет 5, то вряд ли получится что-то серьезное, т.к. слишком много ньюансов.
A>Тривиальные задачи типа прочитать/записать XML или какой-то другой JSON превращаются в кучу работы, с тоннами рукописного кода и кучей возможностей понаделать ошибок
Что-то не верится, что с XML, JSON, и подобными действительно тривиальными задачами дело в C++ обстоит вот так вот уж прям в 9000 раз хуже, чем в Java.
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, CreatorCray, Вы писали:
PM>>Вот что, а сборка Boost ни разу не проблема, даже на Windows
CC>Надобно заметить что tяue cборка без проблем на Windows выглядит как набор .sln + .vcproj а не какие то странные скрипты.
Даже на Windows есть как минимум MinGW и, может быть, будет Clang, так что набором .sln + .vcproj не удастся ограничиться.
Конечно, bjam — то еще изобретение, но я не знаю других систем сборки с такой же возможностью быстро задать разные варианты сборки и собрать их все. По-моему, для универсальной кросс-платформенной библиотеки типа Boost это самое то. Проект по переводу сборки Boost на CMake забуксовал и новостей оттуда не слышно.
Разработчики Boost сделали всё возможное, чтобы минимизировать усилия сборке. Для тех, кто и это не смог осилить есть бинарные дистрибутивы и пакеты, в том числе и в NuGet.
Так что сборка Boost ни разу не проблема, даже на Windows
Н>Чем то напоминает кунг-фу: порог вхождения высокий, всё долго и дорого, у каждого оно лучше чем у других, но результаты восхитительны.
Ок, ну значит ежели Ц++ — это кунг-фу, получается, Ява — это ММА: порог вхождения низкий, все быстро и дешево, через год тренировок будешь на ура заваливать мастеров кунг-фу, которые от банального прохода в ноги защититься не умеют
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, StanislavK, Вы писали:
SK>Интригующий заголовок, но вопросто не в измерении длинны сами знаете чего Прошу на касаться вопросов производительности.
SK>Вопрос в следующем, если бы вам пришлось начать разрабатывать большую серверную, многопоточную, многокомпонентную, распределенную систему, то какой язык бы вы выбрали?
C++
SK>Я сам явист, в качестве бефитов явы в данном контексте, я вижу следуюшее: SK>1. Развитая система билда (maven, gradle) с поддержкой зависимостей, модулей и т.д.
Ты просто не знаешь современные билд-системы C++. К тому же, (maven, gradle) -- это уже не совсем билд-системы, а гораздо больше. далеко не факт, что это "больше"
для С++ нужно -- там это делается другими средствами, поскольку бинарный код не кроссплатформный.
SK>2. Реально много библиотек и фреймворков. Надо встроить вебсервер — не проблема, надо математическую билиотечку, тоже пожалуйста, надо какой-нить complex event processing — все есть и т.д.
На С++ сейчас тоже дофига хороших библиотек.
SK>3. Хорошая совместимость с БД, мессаджингом и т.д. Драйвера есть для всех известных мне продуктов.
У С++ всё равно лучше.
SK>4. Легко (это все кончено относительно) интегрирутеся со всем чем угодно, есть JNI, можно в пол-тычка сделать rest-сервис и т.д.
Ну, REST-сервис вообще на чём угодно сделать очень легко, потому что REST -- это идеология, а не технология.
SK>5. Есть очень хорошая среда разработки (IntelliJ), которая легко работает (рефакторинг, поиск и т.д.) с проектами в десятки тысяч файлов.
IntelliJ CLion.
SK>6. У меня лично есть опыт как это все делается на Java. Насколько реально человеку "со стороны" сделать такое на C++? SK>Подскажите как там у С++ в этом плане.
Да всё хорошо, проблема как всегда с "сделать".
А так -- Java настолько дебильный язык и технологии, что я бы не решился с ними связываться вообще.
Единственный бриллиант там у них -- Java-машина.
Но если и делать что-то на ней, то не на Java и не на традиционных стеках фреймворков.
Легче самому сделать всё это на С++, чем разбираться в том зоопарке нелепых технологий, которые нагородили вокруг Java.
KP>По моим ощущениям, JNI не самая интуитивно понятная штука. Поэтому, если с этой стороны подойдете, то либо заранее разберитесь с JNI, либо найдите человека которой в этой хреноте разбирается.
Есть еще вполне положительный опыт ухода от JNI в сторону нативного standalone сервиса-числодробилки. Общение — через сокеты + протобуф. Это оказалось более надежным(падение дробилки не валило процесс жабы) и простым в поддержке, заодно дало возможность выделить дробилки на отдельные сервера.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Прошу на касаться вопросов производительности.
