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

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

Я бы сюда добавил вопрос количества одновременных клиентов у сервера. Если это внутрифирменное приложение с не более чем сотней клиентов, то C# может потянуть. Если одновременных клиентов тысячи, то быстродействия C# не хватит.

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

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

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

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

Я бы сюда добавил вопрос количества одновременных клиентов у сервера. Если это внутрифирменное приложение с не более чем сотней клиентов, то C# может потянуть. Если одновременных клиентов тысячи, то быстродействия C# не хватит.

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

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