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