Станислав Макаров

Возьмем например Дропбокс.

Изначально был написан на Python - это быстрее для прототипирования.
Потом был переделан на Go - для предсказуемости и скорости. Но зачем переделывать полностью? Многие куски на Python существуют там до сих пор. И работают.
И маааалюсенький кусочек был переделан на Rust - для ускорения самого узкого места.

Вот вам и 3 языка работающих одновременно в Дропбоксе на бэке.

Или имеется в данный момент свободен тот или иной специалист, который лучше знает тот или иной язык. Ему поручили - он сделал на том, что лучше знает, чтобы сделать быстрее и качественнее.

Или такова была особенность задачи. Пример с комбинацей Rust/Go выше приведен. Где то может быть лучше один язык, где то другой.

А если мы вспомним, что проект не только пишется, а еще и готовые компоненты применяются - то автоматически к любому почти проекту добавляются С/С++ те что в БД к примеру и пр. и пр. SQL - тоже язык бэкенда. И пр. и пр.

Вы преувеличивайте значение языка. Это всего лишь инструмент программиста. Такой же как клавиатура. Опытный программист за долгие годы изучает не меньше десятка языков, а кто то и намного больше. Ничего такого в этом нет.

По сути статический массив это действительно указатель. Но реально тип другой и компилятор знает реальный размер массива. После того как вы приводите массив к типу указателя (например при передаче в функцию), эта информация теряется и sizeof уже вернет размер указателя.

Использовать библиотеку длинных чисел, например GMP.

Кое-какие вещи есть, но я бы не сказал, что ими активно пользуются в промышленной разработке. А причина проста: C++ предоставляет слишком много контроля, и слишком сложен, в сравнении с популярными для веб языками PHP, Python, Ruby и т.п. Помимо этого, он ещё и компилируемый, без рефлексии из коробки, с проблемами с ABI и т.д. Т.е. придётся преодолевать много трудностей и учиться многим вещам, при весьма сомнительной пользе для веб.
Разумное использование, это например писать какие-то расширения на стороне сервера, или расширения к БД. Но только не фреймворки вроде RoR.

clion

Да. Читайте про статическую линковку.
Помимо этого, можно просто все нужные зависимости поставлять с исполняемым файлом.

Идея - ничто. Вопрощение - всё. Открываете hh смотрите какие компании нанимают людей и чем они занимаются - делаете лучше. Готово.
К тому же мы не знаем будущего, не знаем какая идея на миллион, а какая на ноль )

Да в любом тесте мне понадобится поле _workers. Как его получать?

Никак. Если говорить по хорошему, этот код невозможно протестировать. Поэтому, например, при TDD не используются статичные классы. Разработка через тестирование заставляет в первую очередь думать что пишешь. Зачем нужна обертка вокруг в виде класса Office вокруг класса List? Какие задачи она решает? Почему в том месте, где будет использоваться интерфейс IOffice не использовать просто класс List? Когда начинаешь задумываться над такими вещами, тогда отпадает надобность получать доступ к приватным полям.

Попробуйте request.Accept