Rust, история успеха. TIOBE, июль 2025, почетное 18 место.

страдать в офисе с компиляцией куда проще и быстрее

Нет. Мой пойнт в том, что проблема программы имеет определённую сложность. Её нельзя качественно уменьшить поменяв алфавит и правила составления предложений. Если сложность условно 10 Колмогоровых, то она и останется такой как ты не приседай.

эскалаций меньше, все довольны

Эскалаций не будет, если нет рабочей программы. Хитрый план, чо.

tiobe это ихний ресурс, отражает глобальные тенденции. а хаха - наш родимый, отражает лишь планы партии и правительства.

почему это произошло - оставим эти дискуссии будущим историкам и археологам.

Да тут не нужно быть мудрецом или индейцем «Орлиный Глаз», чтобы увидеть простую истину – в Rust не завезли нормальный OOP, концепцию которого 85%+ программистов впитывают с молоком матери и переносят на новые языки.

Вместо этого завезли трейты, которые достаточно неудобны для переноса существующего OOP-кода на них. Итог – миллионы ООП-программистов резвящихся на полянке TOP-5 сабжевого рейтинга (все языки с сильным OOP за исключением C) так и не могут перескочить на Rust, потому что им требуется изменить подход и переформатировать мышление, а заниматься подобным могут лишь немногие люди, способные уйти с накатанной колеи в сторону чего-то нового.

Отвержение привычного OOP подхода в Rust в итоге и похоронит этот язык, так как делает его неудобным для всяких формошлёпств, web’а, и в т. ч. движков браузеров, где всякие иерархичные CSS/DOM прекрасно накладываются на OOP-иерархию и коряво на трейты.

У них же странный стандарт кодирования, сами себя ограничили и страдают с замедлением. А вот расто-фанаты жалуются на свой прекрасный язык, стоило лишь начать им писать что то реальное:

https://loglog.games/blog/leaving-rust-gamedev/

https://deadmoney.gg/news/articles/migrating-away-from-rust

+ покидают ядро и прочие проекты

в Rust не завезли нормальный OOP, концепцию которого 85%+ программистов впитывают с молоком матери и переносят на новые языки

Спутал программистов с жавистами. Сейчас вообще ФП в моде, вместо этих ваших абстрактных фабрик. В других язычках ООП используется очень ограниченно, без наследования многие вздохнут спокойно.

Нет.

Что нет? Да. Объективно, по количеству затраченного времени, эскалации в полях с анализом крешдампов отнимают СИЛЬНО больше времени, чем страдание с удовлетворением borrow checker’а. За счет переключения контекста команды с текущих задач на эскалацию, за счет согласование доступа, пчелиные танцы с объяснениями что случилось, гаданиями на стектрейсах и так далее.

Мой пойнт в том, что проблема программы имеет определённую сложность. Её нельзя качественно уменьшить поменяв алфавит и правила составления предложений.

Ну так вместо того чтобы придумывать красивые метафоры, за которыми теряется весь смысл происходящего, давай просто метрики посчитаем. Но тогда срача не будет, да?

Эскалаций не будет, если нет рабочей программы. Хитрый план, чо.

Но какое отношение к этому Rust-то имеет? Я знаю людей, которые на нем пишут, они чуть ли не иденственные из моих коллег, кто сроки соблюдает. Ты либо очень сильно оторван от реальности, либо слишком жирно троллишь.

эй, вы там со своего 18 места со вторым через губу не разговаривайте!

tiobe это ихний ресурс, отражает глобальные тенденции. а хаха - наш родимый, отражает лишь планы партии и правительства.

Шта?

Я знаю людей, которые на нем пишут, они чуть ли не иденственные из моих коллег, кто сроки соблюдает.

а ты уверен, что они на расте пишут? в энторнетах полно ai конвертеров из плюсов в раст :)

может они просто тягяют плюсовый код в одном месте, а потом как растовый выкладывают в другом. и в кассу за зарплатой.

а ты уверен, что они на расте пишут?

Конечно.

давай просто метрики посчитаем

Давай. У тебя есть чо?

Я знаю людей, которые на нем пишут

Я знаю гораздо больше людей которые на нём не пишут.

Давай. У тебя есть чо?

Да, у меня есть среднее время анализа падений в полях в три-четыре дня. Сколько с borrow checker’ом надо страдать?

Сколько с borrow checker’ом надо страдать?

Не знаю, ты же предложил посчитать. Давай кейс раст против крестов на интервале года с учётом полной стоимости. Я чёт сильно сомневаюсь что если даже такие исследования были, то корпы этим поделятся.

Не знаю, ты же предложил посчитать. Давай кейс раст против крестов на интервале года с учётом полной стоимости. Я чёт сильно сомневаюсь что если даже такие исследования были, то корпы этим поделятся.

Ну то есть ты ничего не знаешь, ясно.

В rust нужная цель-обезопасить работу с памятью. На этом все хорошее в rust заканчивается. Далее сплошное дерьмо, начиная с синтаксиса, и заканчивая непонятным комьюнити. А ведь можно было бы сделать правильно: добавить в С++ все те самые средства безопасной работы с памятью. Начинания-то уже все есть, нужно было только подразвить. Более того, в мозилле оно так и начиналось в виде расширений для C++. А потом пошло все по бороде, захотели повыпендриваться, создали новый ЯП, непотянули, возникла проблема «переписываний» и куча выскочек с растом головного мозга.

Ну то есть ты ничего не знаешь, ясно.

Ну то есть никаких кейсов у тебя нет, и объективно ты балабол.

В C++ настолько большой список UB, что вычищать их оттуда придется веками.

Ну то есть никаких кейсов у тебя нет, и объективно ты балабол.

Как скажешь, братан, как скажешь.

Уже существует подмножество С++ без UB:

Constant expressions are not allowed to contain undefined behavior.

Constant expressions are not allowed to contain undefined behavior.

Да.

Не знаю, ты же предложил посчитать. Давай кейс раст против крестов на интервале года с учётом полной стоимости. Я чёт сильно сомневаюсь что если даже такие исследования были, то корпы этим поделятся.

Были, затраты - написание продукта (выше плюсов). Поддержка? А нет её. Как потратился на писавших, так и работает.

Как потратился на писавших, так и работает

Очень сомнительное утверждение, т.к. кроме ошибок работы с памятью бывают ещё и другие ошибки, в т.ч. собственно бизнес логике. Я уж не говорю о том, что за год сама эта логика может 10 раз поменяться. В итоге «написание продукта (выше плюсов)» это перманентная ситуация.

Сколько с borrow checker’ом надо страдать?

если ваши ошибки «в полях» в основном из-за работы с памятью, значит у вас слишком примитивные задачи и низкая квалификация разрабов. Потому что это ошибки самого нубского уровня (типа два раза сказал delete), а нубы не могут решать задачи из сложных предметных областей(не потому что дураки, а потому что нет опыта и привычки писать код правильно).

карочи раст может и спасает от нубских ошибок (от трех штук в год для правильного разраба), но не предоставляет удобных механизмов для решений высокуровневых, а то и вовсе запутывая картину. отчего правильный разраб много страдает и отказывается от языка.а еще более правильный разраб все это видит заранее и даже туда не суется.

в Rust не завезли нормальный OOP, концепцию которого 85%+ программистов впитывают с молоком матери и переносят на новые языки.

Уверен? Я вот слышал просто миллион вопросов вида: «Только что прочитал, что такое ООП. А как мне теперь понять, какие у меня должны быть классы, и что в них должно быть?»

А также видел просто 100500 примеров кода, в которых в классах собирались совершенно не связанные друг с другом вещи, иерархии классов совмещались по невообразимому принципу.

ООП - это не интуитивно понятная вещь для всех.

На всех собесах лет 10 спрашивают про принципы SOLID. Я ещё ни на одной работе не видел, чтобы код соответствовал всем им, или хотя бы большинству из них. Хотя все разработчики собесы как-то проходят и аббревиатуру расшифровывают.

если ваши ошибки «в полях» в основном из-за работы с памятью, значит у вас слишком примитивные задачи и низкая квалификация разрабов.

Братан, худей.

Очень сомнительное утверждение, т.к. кроме ошибок работы с памятью бывают ещё и другие ошибки, в т.ч. собственно бизнес логике. Я уж не говорю о том, что за год сама эта логика может 10 раз поменяться. В итоге «написание продукта (выше плюсов)» это перманентная ситуация.

Если у тебя продукт переписывают с нуля вместо добавления новых кусков или адаптацию старых,то проблема не в языке, а в архитектуре.

Спутал программистов с жавистами. Сейчас вообще ФП в моде, вместо этих ваших абстрактных фабрик. В других язычках ООП используется очень ограниченно, без наследования многие вздохнут спокойно.

Скажем так: индустрия раз в 5-10 лет кидается в очередную крайность. Причём, кидания в крайности идут по кругу. Каждый раз, крайность преподносится, как ультимативная серебряная пуля.

После очередного витка хайпа, остаётся какие-то 0.005% мудрости, которые перенимаются и остаются с нами далее.

Допустим, мы сейчас находимся на витке хайпа AI. Это не первый и даже не второй хайп AI.

Хайпы ООП и ФП тоже уже прошли, остаётся какой-то гибридный подход.

если ты все время натыкаешься на граблю сегфолта, и это основная проблема твоей жизни, не выбирай новый язык, он не спасет. Просто иди в команду тестировщиков, мышкой кликать.

если ты все время натыкаешься на граблю сегфолта, и это основная проблема твоей жизни, не выбирай новый язык, он не спасет. Просто иди в команду тестировщиков, мышкой кликать.

Братан, жирно.

Ну тивоби это ТАКОЕ СЕБЕ. Если отсечь тех кто только лабораторки делает то весь рейтинг пересортируется неожиданным образом. На первом месте должен быть его величество ЖАБАСКРИПТ. Думаю с этим очевидным фактом никто спорить не будет.

проблема не в языке, а в архитектуре

Именно. Язык тут вообще никаким боком. Поэтому-то аргумент, что «один раз дорого написал, зато потом забыл» не принимается.

Именно. Язык тут вообще никаким боком. Поэтому аргумент, что «один раз дорого написал, зато потом забыл» не принимается.

Почему? Один раз написал, дальше дописываешь, на баги времени не тратишь, рефакторинг вносит меньше регрессий.

Почему

Ну ты как-то определись со стулом.

Ну ты как-то определись со стулом.

Ладно, с тобой явно не получится какой-то осмысленной дискусии.

Уверен? … в классах собирались совершенно не связанные друг с другом вещи, иерархии классов совмещались по невообразимому принципу.

ООП - это не интуитивно понятная вещь для всех.

Я ещё ни на одной работе не видел, чтобы код соответствовал всем им, или хотя бы большинству из них.

Так речь идёт не про какой-то там идеализированный и стройный OOP-подход в вакууме аля Smalltalk, а про корявенькие OOP-реализации существующих язычков типа Java, C++, C#, Python и др.

В которых именно что миллионы индусо-программистов нарушают в своих классах все мыслимые и немыслимые SOLID, KISS, YAGNI, GRASP, тысячи их, но при этом пишут и быстро рождают какие-то продукты которые нужны здесь и сейчас. А в Rust экосистеме все эти миллионы специалистов привыкших лабать наследуемые классы с методами остаются не у дел, в итоге в рейтингах Rust занимает низкие места.

https://survey.stackoverflow.co/2024/technology#1-programming-scripting-and-markup-languages

Вот более приближенный к реальности рейтинг, чем тот что публикует TIOBE.

https://imgflip.com/i/a0b8bd

P.s. извините, я с телефона.

явно не получится какой-то осмысленной дискусии

ЛОЛ. Наш диалог:

Ты: язык не важен.

Я: да, не важен.

Ты: Почему?

Напомнило мне: «Да не согласен я. С кем: с Энгельсом, или с Каутским? С обоими!».

Так SO умирает уже, престарелые снобы задушили зумерье. Тут надо Гопатыча спрашивать, про что у него больше интересуются. Кстати, мне кажется это была бы самая актуальная статистика по многим вещам.

Популярней Котлина - стандартного языка для разработки на Android. Вообще норм, учитывая, что это рейтинг поисковых запросов, ибо на нейронки многие перешли для большинства вопросов.

Даже я, не будучи экспертом по C, открываю наугад почти любую библиотеку/приложение на C, и, как минимум, вижу массу потенциальных утечек памяти

ты же понимаешь, что между «подумать о огурце в заднице» - не то же самое, что стать гомиком? Это я к тому, что «потенциальные» утечки представляют больше академический интерес, если нельзя здесь и сейчас применить эксплоит. Нет, я не против всяких контор типа пивас-студио, и не против раста тоже, это капитализм, и пусть друг с другом конкурируют. Но есть некий вселенский принцип минимизации количества телодвижений, согласно которому всё вокруг нас развивается, и живое, и мёртвое. И вот этот принцип подсказывает нам, что вовсе не все баги нужно фиксить. Ну, типа, зачем напрягаться на ровном месте?

Я про tiobe узнал сегодня

то есть программируете со вчера?

И вот этот принцип подсказывает нам, что вовсе не все баги нужно фиксить. Ну, типа, зачем напрягаться на ровном месте?

С этим согласен. На 100% искоренить все баги, причём на любом языке, невозможно.

есть еще такой рейтинг https://pypl.github.io/PYPL.html

С этим согласен. На 100% искоренить все баги, причём на любом языке, невозможно.

Но можно перестать давать шелл когда на единичку ошибся.

Если я писал на каком-то языке 20 лет назад, это не значит, что я его знаю. Знания сохраняются лишь при постоянном использовании.

Ты еще по утрам скорее всего просыпаешься не совсем тот, который засыпал. Но это не значит что тебе заново приходится учиться ходить и дышать, или ездить на велосипеде. Или вспоминать про циклы-ветвления. База, если есть, остается, пригодная в любом стоящем языке. Какие там невпупенные знания еще надо сохранять черзе 20 лет – хз. Модный синтаксический сахарок бывает не бесплатен и неоптимален. А большинство фреймворков (ТМ) в принципе на таком треке не проживет. Все это кококо про «постоянное использование» выглядит как заранее бредовая пропаганда херок и прочих кукаретиков, чтоб низводить и курощать на многоступенчатых собесах «хитрыми» вопросами про фичи, использование которых в реальных проектах не встречается примерно никогда.

Я вот на Perl довольно много писал 25 лет назад.

Бггг, еще бы произвольный ассемблер привел в пример.

Сейчас я не уверен, что смогу написать «Hello, world» на Perl.

Ну либо и тогда не особо знал, либо пользовался «компактным подмножеством фич», достаточным для этого «много писал».

База, если есть, остается, пригодная в любом стоящем языке. Какие там невпупенные знания еще надо сохранять черзе 20 лет – хз.

Тонкий баланс между полезными фичами языка, которые не превращают кодовую база в лапшу. Как конкретно в этом языке лучше организовать композицию модулей кода. Какие части библиотеки ок, а какие лучше не брать, потому что они не очень вышли.

Если ты думаешь что время выхода на рынок зависит от языка, то ты явно не понимаешь о чем говоришь.

Любопытно. Не вел статистику, но есть ощущение, что в прошлом в критике С++ каждая вторая причина оказаться от C++ была как раз в том, что «пока вы C++ный код отлаживаете, версия на Java или C# уже не просто продается, а полностью окупилась».

Любопытно. Не вел статистику, но есть ощущение, что в прошлом в критике С++ каждая вторая причина оказаться от C++ была как раз в том, что «пока вы C++ный код отлаживаете, версия на Java или C# уже не просто продается, а полностью окупилась».

Тогда бы люди не страдали с голангом столько, сколько они с ним страдают.

А как с голангом страдают? просто любопытно, сам на нём непишу, поэтому не знаю