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

_>>1. Первым и ключевым шагом при выборе языка очевидно должно быть рассмотрение его применимости в данной области. ... Чаще всего это задачи в таких областях как: реалтайм, тяжёлые вычисления, низкоуровневая работа с железом или ОС. Но есть и некоторые другие, более редкие.
lpd>Я бы сюда добавил вопрос количества одновременных клиентов у сервера. Если это внутрифирменное приложение с не более чем сотней клиентов, то C# может потянуть. Если одновременных клиентов тысячи, то быстродействия C# не хватит.

Безусловно. Там вообще можно ещё много узких областей назвать, где C# и ему подобные языки не подойдут. Я назвал только самые общеизвестные.

_>>2. Вторым шагом будет вопрос наличия в команде или потенциальной возможности нанять команду реальных специалистов по C++. Это не такой простой вопрос как кажется. Дело в том, что наверное 95% программистов заявляющих, что они умеют работать на C++, на самом деле даже близко не являются приемлемыми профессионалами в нём. А этот язык требует именно профессионализма. Даже если ограничиться самым самым минимумом, типа знания современного стандарта (C++17) и библиотек Boost (стандарт де-факто в мире C++), то уже легко отсеивается большинство "претендентов", а это ещё только верхушка айсберга. ... В отличие от команды слабых программистов на C++, которая скорее всего вообще завалит проект.
lpd>Ну вот: наслушались C++17 евангелистов, и теперь на C++ не пишут, только на С++17. Я мог бы пройтись по С++17 и показать, что половина фич либо нужна очень редко, либо вообще нужна только для исправления костылей других фич, а в нормальной разработке применяться не должна.

В С++17 действительно нет особо принципиального, так же как и в C+14, которые по сути получились доработкой революционного стандарта C++11. Хотя иx конечно же тоже желательно знать. А вот незнание всех возможностей C++11 тоже до сих пор встречается и является абсолютно не приемлемым для претензии на знание C++.

lpd>В результате язык как снежный ком обрастает новыми ключевыми словами и классами, все исключительно ради того, чтобы всегда использовать stl и ни при каких условиях не использовать прямое управление памятью(move-семантика, auto, shared_ptr). В то время как stl, вообще то, изначально задумывался как упрощение программирования, а не замена знания алгоритмов на знание C++17. C++11-17 — это попытка сделать из C++ то, чем он стать не может.

Вообще то move-семантика — это как раз реальная киллер-фича, которая принципиально увеличивает эффективность кода. Причём каких-то даже близких аналогов этой фичи нет ни в одном из мейнстрим языков.

lpd>Поэтому знание С++11-17 нужно приветствовать, однако заявлять, что все программы на классическом C++ (или С) плохие, не следует.

Программы то может и не плохие. Но если уж начинать сейчас новый проект, то очевидно, что глупо не использовать возможности современного C++.