Так оно тоже достаточно часто отвечает. Но если "думает", что знает ответ, то начинает писать абстрактное кэпство.
Подозреваю, что какой-то следующий круг усилий по совершенствованию этих моделей будет направлен как раз на улучшение качества самопонимания... и это как раз то, что приблизит реально к человеческому уровню (ну, имеющего образование в данной области).
Если в интернете нет описания чего-то, то шанс на генерацию полезного ответа - минимален. Собственно, по этому часто и видно, что данных нет, или надо менять формулировку.
Итого, все ваши высказывания про гуманитариев противоречат общеизвестным фактам. Это лично вы не способны на физику, а не гуманитарии.
А может, это физик оказался способен ещё и картины рисовать, а не наоборот? ;)
По-моему, ваш оппонент говорил о статистической закономерности - а один пример одного великого художника её не опровергает, подчёркивая, наоборот, её наличие.
Я бы сказал, основная проблема в том, что любая IT технология в период бурного развития даёт 99% шума-хайпа и только 1% того, что станет полезным. Это касается не только IT, а значительной части прогресса в целом, но в IT за счёт общих темпов это выражено значительно острее. Автор вспоминает ML/DS, но ML/DS десять лет назад были примерно таким же по шуму, а до этого были другие, включая компьютеры в целом.
Так что ещё 10 лет и мы сможем понять, что же реально выжило и стало полезным, а рядом будет что-то ещё хайповать.
Если бы автор не матерился, я бы подумал, что это James Mickens. Но хорошо, что остались ещё авторы хороших сатирических проездов. Они пользительны и прельстивы.
ни на одном языке вообще нельзя сравнивать дробные числа на равенство!
Можно и нужно - но, понимая, что именно делаешь и почему. И имея в виду возможные проблемы от реализации. А вот если не понимать... вот тут целое собачье кладбище зарыто.
В обсуждаемом случае сравнение int и float - это не сравнение двух float. Это отдельный вариант (хоть внутри и получается конверсия к float (double), но она замаскирована видом констант). И последствия от него примерно такие же, как в JS ситуация типа "ваш номер карточки 4.1492103e+15". Это больше проблема типизации, чем собственно сравнение floatʼов.
Сравнение floatʼов на равенство вредно тогда, когда мы говорим о результатах вычислений с заведомо приближёнными значениями (типично для прикладной математики всех видов выше, чем 4 арифметические операции). Вот там появляется правило про корректный выбор относительной погрешности (каковой выбор ещё надо осилить, не всегда сразу получается адекватная погрешность).
А вот если значения по каким-то причинам точные (или гарантированно точные, или результат однозначно определённых операций типа i*0.01), тогда и точное сравнение возможно. Также есть случаи сравнения с нулём, как признак полной потери значения (даже не денормализованные). Но очень часто само по себе такое сравнение подсказывает, что выбрана неверная модель представления числа.
В финансовых расчётах точное сравнение возможно и нужно. Но тут вопрос, с какого момента может начаться недопустимое округление. Всякие Decimal из С# маскируют проблему до предела, давая аж до 28 знаков точности... обычно хватает. Но с фиксированной точкой таки честнее (и проблема, если что, выскочит явно).
Но попросту, конечно, можно сказать "нельзя!" и это будет как деление на ноль ;)
База данных является краеугольным камнем любого проекта.
Посмотрел на несколько последних проектов, в которых участвовал.
SIP софтсвич. Общается с чем-то, представляющим себя как биллинг, по кастомному протоколу (RADIUS с вендорскими расширениями). Ну база тоже есть, но очень вспомогательная.
Компонент радиосоты, управление локальной конфигурацией, которая задаёт направление потоков данных через кастомизированное железо. О "базе данных" можно говорить только в плане состояния этой конфигурации в памяти между ребутами. Есть, конечно, центральная база (на всяких etcd), но это конфигурация, которую в основном правят руками.
Можно продолжать...
Я не против статьи в целом, но слишком много упрощений. И почему мне кажется, что вся статья была написана ради одного слова "Swagger"? И чем же он так хорош, что использовать его, а не 100500 аналогов? "Тема <xxx> не раскрыта" (c).
при этом нет никаких проблем с производительностью при работе через виртуальные функции
Потому что на 1 единицу затраты времени на вызов виртуальной функции приходится 1000 или 100000 затрат на энкодинг-декодинг, даже с учётом всего ускорения через вылизанный векторный код поверх последнего SSE, BMI2 и прочих вкусняшек.
И поэтому же какие-нибудь считаемые на GPU нейросети работают под запускалкой на Python - затраты Python, в 30-100 раз больше даже самого неоптимального кода на C, не имеют значения.
А вот где нет такого отношения времён, там вы не отделаетесь. Во внутренностях кодеков как раз инлайнинг на интринсике сидит, вектором погоняет, и виртуальным функциям там не место.
Более того если бы видео плеер был построен с использованием шаблонов пришлось бы каждый раз все перекомпилировать при добавлении нового формата данных, нового кодека.
Такой себе AST в виде списков и деревьев, только на JSON.
В реальном, конечно, будет много отличий (например вместо "x" в выражении, скорее всего, будет что-то вроде {"local":"x"}), но внешне будет достаточно похоже.
европа, китай, индия и сша. Ставка 30 долларов в час это средний доход.
Нет, вы слишком хорошо думаете о среднем доходе. Разделите минимум на два. Для Индии ещё больше.
AWS вам подойдет как ответственный сервер? S3 стоит $0.0125 per GB, стоимость мегабайта в рублях посчитайте сами.
S3? Конечно, не подойдёт, это потоковое хранение, а не устройство прямого доступа, и не обязательно настолько быстрое даже как HDD, часто - в разы медленнее (его могут держать на очень медленных дисках типа черепичной записи, через забитые каналы, и всё такое).
Как активный диск у Амазона (пусть мы смотрим таки на Амазон) надо смотреть, например, на EBS, и вот тут уже видно - provisioned IOPS (мы ж хотим гарантированную полосу?) это 125$/TB/месяц (открыло Ohio, пусть будет оно). Это соответствует расходу одного такого диска в месяц, или комплекта RAID за 4 месяца. Деля ещё на 2 за on-demand вариант (а не предоплаченный на 3 года, как аналог персонального железа), соответствует 8 месяцам. Ну, износить SSD за год активным общением это как пить дать. Кстати, там в цене ещё сами IOPS надо добавить, а не только хранилище для них:) Так что Амазон тоже на активном дисковом хранилище использует какой-то RAID, как я и описывал.
Собственно, упоминания S3 достаточно, чтобы понять, что вы упорно сравниваете паровозы с апельсинами, и, или 1) не понимаете вообще, что сравниваете несравнимое, или 2) активно троллите. Выбирайте сами.
200GB диск, желязка, полминуты на скачивание - какие-то истории из 2004 года. Ваша "желязка" случайно не по модему в 28800 бод соединение держит?
2024. Нет, это чистая реальность из этого года. Головная станция интернет-доступа. И тоже или даже не подумали калькулятор взять, или троллите. Полминуты на 28800 это ~86kB, а не гигабайт. Мне уже как-то надоедает вести беседу на таком уровне.
Причему тут стековые фреймы, что за каша началась.
При том, что они оправдывались за очень лёгкое разбухание совсем не мегабайтных программ.
Если это для вас каша... вместе с вашими странностями арифметики, которые должны были быть исправлены где-то в средней школе, я не думаю, что эту дискуссию имеет смысл продолжать.
Жесткий диск в 1 терабайт стоит как два часа работы среднего программиста
Вы показываете просто потрясающий пример, как можно не понимать проблему и при этом её опошлить до якобы несуществующей.
1. Какой "жёсткий диск"? HDD? Замечательно. В типовом лаптопе сейчас SSD на M.2. За 1TB это будет 100$. "Средний программист" exUSSR получает где-то 2000$/месяц, то есть это уже день, а не два часа. Это пока что уровень разработки. Или вы про "среднего программиста" Кремниевой долины? Там, конечно, и час будет, но таких мало от общего числа по миру.
2. Если мы говорим про ответственный сервер, то там цена быстрого надёжного хранилища будет равна минимум 4 таким дискам плюс контроллер для RAID 5/6/Z. Ладно, контроллер софтовый (не всегда адекватно, но упростим) - всё равно умножили на 4. Не буду считать это в 4 днях работы разработчика, хотя сколько тех серверов нужно для реального сервиса - может, и 1000... это уже 11 лет зарплаты одного такого программиста. Ладно, 3 года, если из Фремонта или Санта-Анны. И 20-30 лет, если из Бангалора:))
3. Теперь, говорим про железяку на выносе (мой последний случай именно такой). Диск - флэшка на ~200GB, SD card. Уже занято ~70% на старте, ещё ~20% выделено на логи. И ещё требуется скорость обновления, каждые 10 секунд на счету, потому что это массовое падение сервиса - железяка обслуживает несколько тысяч клиентов. Лишний гиг несжимаемого (именно так) бинаря, по мегабайту на тысячу рабочих программ - реально, полминуты на скачивание (по совсем не свободным каналам, у юзеров звонки и трафик, а на сервере драка сотен скачивающих) плюс где-то столько же на заливку на флэшку.
Понимаете, почему расчёт на один HDD это, ничего личного, просто ламерство? И почему, например, убунтовцы в 24.04 говорили "очень-очень-очень извините, но наши стековые фреймы стоят пару процентов места и времени, но нам всем эта пара процентов много даёт непоправимой пользы, поэтому мы таки сделали"?
Сейчас я не в "бегемоте". Но - вы понимаете, что у них есть свои задачи и кто-то должен их исполнять? Если все хоть сколько-то вменяемые сбегут, то те, что останутся - что они построят?
Я полагаю каждый такой эксцесс (головомойка когда выясняется что приехал пожилой человек, а не младенец) стоит компании кратно выше, чем "экономия на тестах", "экономия на байтах" и пр..
Думаю, нет, если учесть цену всех административных действий - оформить проблему, продавить хотя бы оценку фикса через начальство, сделать эту оценку, расписать ТЗ, расписать тесты, сделать реализацию, проверить, разлить на все рабочие системы... реально на миллионы выйдет, если не на десятки миллионов. Обычно в таких "бегемотах" подобные изменения возможны только при выкатывании принципиально новой системы.
Ну и в целом, если писать код не ногами, то никаких особенных тестов на >100 и не нужно.
Нужно - на каждый элемент обстановки. Число пишется в распечатке? Изменение формата. Кто-то должен описать требования, что сохраняется, что меняется, как тестировать. Где-то от этого поплыло форматирование, форма не влезла на страницу, скандал, переделка. Число вводится вручную? 3 цифры вместо 2, продумать новый лимит (не 999 же позволять?), сколько - 120? 150? 199? 200? Вопрос сложный, хоть на высшее руководство поднимай, принять самостоятельное решение на нижнем уровне побоятся. 2 байта в структуре вместо одного? Где-то фиксированные смещения заложены, всё поплыло, 99% мест починили, одно сломалось. Какой-то формат данных не позволяет 2 байта, позволяет только или 1, или 8 (вспоминается ZeroMQ) - выход за границы размера какой-то датаграммы, буфера переполнены, в тесте не найдено, потому что в тесте никто не подумал совместить одновременно такой возраст, звание "доктор" вместо "мистер" и одновременно 10 скидок на разные аспекты полёта. Я могу этот поток сознания про разные хохмы продолжать ещё долго только на своём опыте...
Напомнило историю, как у кого-то в свидетельстве о рождении было указано 31 ноября. Что именно вбивать в базе данных детсада, решалось в итоге волевым решением директора.
Но при этом растет доля проектов(в основном веб-сервисов), написаных на более простых языках - typescript, C#/java, go.
Ну вот у вас или CAD с базами данных, или веб-сервисы. А промежуточного вы не видите. Когда-то такие задачи, как email сервер, VoIP-софтсвич, IDE (смотрим на пучок от JetBrains) - можно было писать только на полностью компилируемых языках с ручным управлением памятью, другое не работало. Сейчас IDE - на Java, C#. Свич - какие-нибудь кодекоконвертеры и передатчики RTP - ладно, C/C++, но сигнализация - нафига там C++ когда Java справляется не хуже (а я до сих пор парой пальцев ноги в проекте где Python). Email - аналогично, накой там C++, Java пробовалась уже с 2000 (если это не что-то масштаба Google), хотя Go дышит в затылок. И так далее.
А завтра и CAD будут забирать у C++, потому что нафиг там такое не нужно, кроме, может, пары критичных алгоритмов какой-нибудь сложной разводки. И то, хорошо оптимизированный язык типа C# вполне может за-JITʼиться в сравнимый код. Игровые движки - сколько игр не требуют 144fps и вполне бегают на Unity, а то и на чистом JS?
Постоянное выдавливание классических языков с ManMM, включая C и C++, из всё большего числа применений - это голый факт. C++ позволяет, до какой-то степени, притормозить этот процесс, но не более.
Я к этому думаю также, что если бы Go и Rust не старались паковать всё в один статический бинарник - то уже давно большинство содержимого всяких /usr/bin было бы на них. Сейчас они сами себе тормозят это продвижение (намеренно или нет - понять сложно).
Так оно тоже достаточно часто отвечает. Но если "думает", что знает ответ, то начинает писать абстрактное кэпство.
Подозреваю, что какой-то следующий круг усилий по совершенствованию этих моделей будет направлен как раз на улучшение качества самопонимания... и это как раз то, что приблизит реально к человеческому уровню (ну, имеющего образование в данной области).
Если в интернете нет описания чего-то, то шанс на генерацию полезного ответа - минимален. Собственно, по этому часто и видно, что данных нет, или надо менять формулировку.
А может, это физик оказался способен ещё и картины рисовать, а не наоборот? ;)
По-моему, ваш оппонент говорил о статистической закономерности - а один пример одного великого художника её не опровергает, подчёркивая, наоборот, её наличие.
Простите, а какая именно версия GPT написала этот комментарий?
Я бы сказал, основная проблема в том, что любая IT технология в период бурного развития даёт 99% шума-хайпа и только 1% того, что станет полезным. Это касается не только IT, а значительной части прогресса в целом, но в IT за счёт общих темпов это выражено значительно острее. Автор вспоминает ML/DS, но ML/DS десять лет назад были примерно таким же по шуму, а до этого были другие, включая компьютеры в целом.
Так что ещё 10 лет и мы сможем понять, что же реально выжило и стало полезным, а рядом будет что-то ещё хайповать.
Если бы автор не матерился, я бы подумал, что это James Mickens. Но хорошо, что остались ещё авторы хороших сатирических проездов. Они пользительны и прельстивы.
Можно и нужно - но, понимая, что именно делаешь и почему. И имея в виду возможные проблемы от реализации. А вот если не понимать... вот тут целое собачье кладбище зарыто.
В обсуждаемом случае сравнение int и float - это не сравнение двух float. Это отдельный вариант (хоть внутри и получается конверсия к float (double), но она замаскирована видом констант). И последствия от него примерно такие же, как в JS ситуация типа "ваш номер карточки 4.1492103e+15". Это больше проблема типизации, чем собственно сравнение floatʼов.
Сравнение floatʼов на равенство вредно тогда, когда мы говорим о результатах вычислений с заведомо приближёнными значениями (типично для прикладной математики всех видов выше, чем 4 арифметические операции). Вот там появляется правило про корректный выбор относительной погрешности (каковой выбор ещё надо осилить, не всегда сразу получается адекватная погрешность).
А вот если значения по каким-то причинам точные (или гарантированно точные, или результат однозначно определённых операций типа i*0.01), тогда и точное сравнение возможно. Также есть случаи сравнения с нулём, как признак полной потери значения (даже не денормализованные). Но очень часто само по себе такое сравнение подсказывает, что выбрана неверная модель представления числа.
В финансовых расчётах точное сравнение возможно и нужно. Но тут вопрос, с какого момента может начаться недопустимое округление. Всякие Decimal из С# маскируют проблему до предела, давая аж до 28 знаков точности... обычно хватает. Но с фиксированной точкой таки честнее (и проблема, если что, выскочит явно).
Но попросту, конечно, можно сказать "нельзя!" и это будет как деление на ноль ;)
Посмотрел на несколько последних проектов, в которых участвовал.
SIP софтсвич. Общается с чем-то, представляющим себя как биллинг, по кастомному протоколу (RADIUS с вендорскими расширениями). Ну база тоже есть, но очень вспомогательная.
Компонент радиосоты, управление локальной конфигурацией, которая задаёт направление потоков данных через кастомизированное железо. О "базе данных" можно говорить только в плане состояния этой конфигурации в памяти между ребутами. Есть, конечно, центральная база (на всяких etcd), но это конфигурация, которую в основном правят руками.
Можно продолжать...
Я не против статьи в целом, но слишком много упрощений. И почему мне кажется, что вся статья была написана ради одного слова "Swagger"? И чем же он так хорош, что использовать его, а не 100500 аналогов? "Тема <xxx> не раскрыта" (c).
Я не смог нагуглить цитату и контекст, слишком много мусора в поиске. Есть точная ссылка?
Потому что на 1 единицу затраты времени на вызов виртуальной функции приходится 1000 или 100000 затрат на энкодинг-декодинг, даже с учётом всего ускорения через вылизанный векторный код поверх последнего SSE, BMI2 и прочих вкусняшек.
И поэтому же какие-нибудь считаемые на GPU нейросети работают под запускалкой на Python - затраты Python, в 30-100 раз больше даже самого неоптимального кода на C, не имеют значения.
А вот где нет такого отношения времён, там вы не отделаетесь. Во внутренностях кодеков как раз инлайнинг на интринсике сидит, вектором погоняет, и виртуальным функциям там не место.
А теперь загляните внутрь самого кодека...
Что именно из высказываний Вирта вы тут имеете в виду?
Ну например вот функция сложения двух чисел
Такой себе AST в виде списков и деревьев, только на JSON.
В реальном, конечно, будет много отличий (например вместо "x" в выражении, скорее всего, будет что-то вроде {"local":"x"}), но внешне будет достаточно похоже.
Нет, вы слишком хорошо думаете о среднем доходе. Разделите минимум на два. Для Индии ещё больше.
S3? Конечно, не подойдёт, это потоковое хранение, а не устройство прямого доступа, и не обязательно настолько быстрое даже как HDD, часто - в разы медленнее (его могут держать на очень медленных дисках типа черепичной записи, через забитые каналы, и всё такое).
Как активный диск у Амазона (пусть мы смотрим таки на Амазон) надо смотреть, например, на EBS, и вот тут уже видно - provisioned IOPS (мы ж хотим гарантированную полосу?) это 125$/TB/месяц (открыло Ohio, пусть будет оно). Это соответствует расходу одного такого диска в месяц, или комплекта RAID за 4 месяца. Деля ещё на 2 за on-demand вариант (а не предоплаченный на 3 года, как аналог персонального железа), соответствует 8 месяцам. Ну, износить SSD за год активным общением это как пить дать. Кстати, там в цене ещё сами IOPS надо добавить, а не только хранилище для них:) Так что Амазон тоже на активном дисковом хранилище использует какой-то RAID, как я и описывал.
Собственно, упоминания S3 достаточно, чтобы понять, что вы упорно сравниваете паровозы с апельсинами, и, или 1) не понимаете вообще, что сравниваете несравнимое, или 2) активно троллите. Выбирайте сами.
2024. Нет, это чистая реальность из этого года. Головная станция интернет-доступа. И тоже или даже не подумали калькулятор взять, или троллите. Полминуты на 28800 это ~86kB, а не гигабайт. Мне уже как-то надоедает вести беседу на таком уровне.
При том, что они оправдывались за очень лёгкое разбухание совсем не мегабайтных программ.
Если это для вас каша... вместе с вашими странностями арифметики, которые должны были быть исправлены где-то в средней школе, я не думаю, что эту дискуссию имеет смысл продолжать.
Вы показываете просто потрясающий пример, как можно не понимать проблему и при этом её опошлить до якобы несуществующей.
1. Какой "жёсткий диск"? HDD? Замечательно. В типовом лаптопе сейчас SSD на M.2. За 1TB это будет 100$. "Средний программист" exUSSR получает где-то 2000$/месяц, то есть это уже день, а не два часа. Это пока что уровень разработки. Или вы про "среднего программиста" Кремниевой долины? Там, конечно, и час будет, но таких мало от общего числа по миру.
2. Если мы говорим про ответственный сервер, то там цена быстрого надёжного хранилища будет равна минимум 4 таким дискам плюс контроллер для RAID 5/6/Z. Ладно, контроллер софтовый (не всегда адекватно, но упростим) - всё равно умножили на 4. Не буду считать это в 4 днях работы разработчика, хотя сколько тех серверов нужно для реального сервиса - может, и 1000... это уже 11 лет зарплаты одного такого программиста. Ладно, 3 года, если из Фремонта или Санта-Анны. И 20-30 лет, если из Бангалора:))
3. Теперь, говорим про железяку на выносе (мой последний случай именно такой). Диск - флэшка на ~200GB, SD card. Уже занято ~70% на старте, ещё ~20% выделено на логи. И ещё требуется скорость обновления, каждые 10 секунд на счету, потому что это массовое падение сервиса - железяка обслуживает несколько тысяч клиентов. Лишний гиг несжимаемого (именно так) бинаря, по мегабайту на тысячу рабочих программ - реально, полминуты на скачивание (по совсем не свободным каналам, у юзеров звонки и трафик, а на сервере драка сотен скачивающих) плюс где-то столько же на заливку на флэшку.
Понимаете, почему расчёт на один HDD это, ничего личного, просто ламерство? И почему, например, убунтовцы в 24.04 говорили "очень-очень-очень извините, но наши стековые фреймы стоят пару процентов места и времени, но нам всем эта пара процентов много даёт непоправимой пользы, поэтому мы таки сделали"?
Нет, конечно.
Сейчас я не в "бегемоте". Но - вы понимаете, что у них есть свои задачи и кто-то должен их исполнять? Если все хоть сколько-то вменяемые сбегут, то те, что останутся - что они построят?
Это пока далеко не всегда так, дополнительные мегабайт-два на каждую программу - очень дорого.
Думаю, нет, если учесть цену всех административных действий - оформить проблему, продавить хотя бы оценку фикса через начальство, сделать эту оценку, расписать ТЗ, расписать тесты, сделать реализацию, проверить, разлить на все рабочие системы... реально на миллионы выйдет, если не на десятки миллионов. Обычно в таких "бегемотах" подобные изменения возможны только при выкатывании принципиально новой системы.
Нужно - на каждый элемент обстановки. Число пишется в распечатке? Изменение формата. Кто-то должен описать требования, что сохраняется, что меняется, как тестировать. Где-то от этого поплыло форматирование, форма не влезла на страницу, скандал, переделка. Число вводится вручную? 3 цифры вместо 2, продумать новый лимит (не 999 же позволять?), сколько - 120? 150? 199? 200? Вопрос сложный, хоть на высшее руководство поднимай, принять самостоятельное решение на нижнем уровне побоятся. 2 байта в структуре вместо одного? Где-то фиксированные смещения заложены, всё поплыло, 99% мест починили, одно сломалось. Какой-то формат данных не позволяет 2 байта, позволяет только или 1, или 8 (вспоминается ZeroMQ) - выход за границы размера какой-то датаграммы, буфера переполнены, в тесте не найдено, потому что в тесте никто не подумал совместить одновременно такой возраст, звание "доктор" вместо "мистер" и одновременно 10 скидок на разные аспекты полёта. Я могу этот поток сознания про разные хохмы продолжать ещё долго только на своём опыте...
Напомнило историю, как у кого-то в свидетельстве о рождении было указано 31 ноября. Что именно вбивать в базе данных детсада, решалось в итоге волевым решением директора.
Может, это и хорошо, что закончилась. Потому что её ж тут намеренно ограничивают.
(Конечно, лучше было бы наоборот - динамическая только там, где явно разрешено.)
Ну вот у вас или CAD с базами данных, или веб-сервисы. А промежуточного вы не видите. Когда-то такие задачи, как email сервер, VoIP-софтсвич, IDE (смотрим на пучок от JetBrains) - можно было писать только на полностью компилируемых языках с ручным управлением памятью, другое не работало. Сейчас IDE - на Java, C#. Свич - какие-нибудь кодекоконвертеры и передатчики RTP - ладно, C/C++, но сигнализация - нафига там C++ когда Java справляется не хуже (а я до сих пор парой пальцев ноги в проекте где Python). Email - аналогично, накой там C++, Java пробовалась уже с 2000 (если это не что-то масштаба Google), хотя Go дышит в затылок. И так далее.
А завтра и CAD будут забирать у C++, потому что нафиг там такое не нужно, кроме, может, пары критичных алгоритмов какой-нибудь сложной разводки. И то, хорошо оптимизированный язык типа C# вполне может за-JITʼиться в сравнимый код. Игровые движки - сколько игр не требуют 144fps и вполне бегают на Unity, а то и на чистом JS?
Постоянное выдавливание классических языков с ManMM, включая C и C++, из всё большего числа применений - это голый факт. C++ позволяет, до какой-то степени, притормозить этот процесс, но не более.
Я к этому думаю также, что если бы Go и Rust не старались паковать всё в один статический бинарник - то уже давно большинство содержимого всяких /usr/bin было бы на них. Сейчас они сами себе тормозят это продвижение (намеренно или нет - понять сложно).