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