стоит ли запилить тему по с++

правильно, ничем и таких примеров можно на целый альманах накатать - так акий смысл иметь дело с растом?

а перекатать проект с с++ на раст в чистую - это совсем не оверхед???

выкинут чрез некоторое время

вот именно - какой смысл накатывать портянки на новомоде, если под капотом остаётся с/с++, а новомод лишь увеличивает фрагментацию кодов да блоутвару??? если с карбоном выгорит, то можно говорить об отказе от с++, но не от сишечки (кстати говоря). хотя хухль ужо ведёт себя некрасиво..

нежелание финансировать нормально проект может легко его похоронить.

 

расТово-чистых
"это надо говорить четко!"
("Противостояние")

 

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

Зачем перекатывать проекты с одного языка на другой?

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

По той же причине, по которой си выбросили из сферы веб-бэкендов, заменив на Go. Появится что-то удачнее - Go так же попросят освободить пьедестал. Под капотом у него может быть что угодно, но пишут на Go.
С растом то же самое: сообщество просто придумало более удобный инструмент для решения системных задач - безопасный, быстрый, выразительный и просто удобный. Изобретут что-то лучше - и раст выбросят на свалку истории. Но пока ничего лучше не придумали - он будет занимать всё больший и больший процент рынка.

 

https://www.tiobe.com/tiobe-index/

о, как

 

Ну ты это сейчас серьёзно? Ты же понимаешь, что на вершину рейтинга не может попасть язык, на котором написано кода тысячекратно меньше?

Где ты возьмёшь такое же количество специалистов на новом языке? На си и плюсах эти специалисты УЖЕ были, когда раст только появился. Или ты хотел, чтобы за 4 года, когда начался хайп вокруг раста, на него перешла вся индустрия, выбросив миллиарды строк плюсового, сишного и питоновского кода?

 

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

так с/с++ - это ж зло чистой Воды, вот мы все и должны всё на расту перекатить

эта популярность выглядит так..

- раст есмь сама круть, долой ансейф старьё!!!
- ты уже сколько своих проектов на раст откатил?
- да, ппц хочу.. но времени нихЪЪ нет и с деньгами всё хреновей...
=========
Занавес закрывается

отвечаю тебе..

ну, к примеру, по скорости прироста вполне может быть 1ым, но тамо почему-то с++

 

Ты берёшь пограничные случаи, где без переполнения стека обойтись нельзя. Но так и быть, специально для тебя и твоих переполнений в расте есть unsafe.
Но мне кажется, что большинство программ как-то обходятся без необходимости расценивать фатальные ошибки как штатное поведение.

Он не вмешивается, он только говорит: "Вот здесь у тебя несинхронизированный доступ к данным, это небезопасно, здесь гонка, поэтому я это собирать отказываюсь".
Ты, конечно, приведёшь сейчас выдуманный пример, где именно такое поведение необходимо, чтобы всё работало как надо, но будем честны - ни в одном реальном проекте ты такого не встретишь.
А вот гонку из-за забытых блокировок - встретишь, и встретишь часто.

Никто не будет переписывать горы существующего кода, но в новых проектах выбор делают уже не в пользу c/c++ стека.
Более того, даже до популярности раста выбор уже начинали делать в пользу Go/C#/Java/Kotlin. Интересно, почему, если си так хорош.

Это справедливо для любого языка и для любого специалиста, который столкнулся с устареванием своего любимого стека. Кто-то адаптируется и получает плюшки, кто-то ворчит на всё новое. Ничто не ново под луной.

Может, но не должен: не все хотят/готовы на него переходить, намного меньше вакансий, и уже существующие продукты на плюсах, которые надо развивать и поддерживать.

 

Говоря о мнениях авторитетных людей о том, что нужно, а что не нужно (по сабжу начинается с 2:16):

 

Даже если забыть про безопасность, на расте просто приятно писать. Функциональные штучки, дружелюбная асинхронность, но главное - это волшебный Cargo.
На плюсах сто раз подумаешь, прежде чем тащить в проект стороннюю либу и воевать с её сборкой и подключением.
А когда стал писать на расте - заметил, что он буквально провоцирует и поощряет использовать либы: «Эй, дружище, тебе нужна эта фича? У меня есть вот такой классный крейт, который делает именно то, что тебе нужно. Просто пропиши его в конфиг - и готово!».

И что бы ни захотелось - это уже есть на crates.io. Веб-серверы, ORM, дизассемблеры, нейронки - просто бери и пользуйся.
И никаких страданий со сборкой, прописыванием инклудов, линковкой, системами сборки. Буквально на раз-два-три: прописал зависимость, набрал cargo build и you’re good to go. И ты уверен, что проект соберётся и сейчас, и через десять лет. Один только Cargo - причина не связываться с плюсами.

И вторая неочевидная причина - дружелюбные тесты.
Минимальное «расстояние» от кода до теста: не надо заводить отдельный проект, вычленять куски логики из основного кода - пишешь код, тут же покрываешь тестами, тут же запускаешь и сразу видишь результат.

 

HoShiMin, есть гламурные коды и их разрабы могут писать их аки им вздумается, а есть промышленные коды - и там выбор инструментов предельно прост (сишечка да ассемблеры), даже морду у проги часто пишут на сишечки, чтобы она жрала минимум батареи. хорошим примером промышленных кодов является ютуб - задайся Вопросом: почему эти ребята пишут тонны кодов ансейф старьём, а супер-пупер хакЭры так и не смогли ютуб положить.. что же тамо за магия такая?

 

Ну мне не очень нравится синтаксис, для натива мне больше импонирует Ним. Хоть и в целом Раст более развит в плане комьюнити и библиотек.

Во-первых, Петухона там скорее всего куда больше, во-вторых, наружу торчит Петухон, а не Цэ. И вообще, где статистика по использованию языков в ютюбе?

 

Видел, сколько кода в сливе яндекса? А в гугле его ещё больше. Переписать его весь за разумный срок - близко к невозможному.
А вот результаты того, что они успели переписать: https://www.zdnet.com/google-amp/ar...lashed-android-memory-safety-vulnerabilities/

https://blogs.grammatech.com/memory...ource-of-security-vulnerabilities?hs_amp=true

 

главная часть ютуба/хухля кроется в файловой системе с заточкой под потоковые операции (то бишь сортировка данных там лишь частичная). https://en.wikipedia.org/wiki/Bigtable
из железок тянут последние соки, а это лишь низкоуровневые оптимазы.
HoShiMin, и что с того?

 

Так и чего? Плюсы, а не сишечка. Торчит это в интернет по твоему, чтобы его ломали? Какой процент кода ютюба составляет этот проект, статистика где? И дата выхода сто лет в обед, сейчас бы ее начинали писать не на плюсах, о чем тот же Руссинович и говорит всем, но только адепты не выкупают до сих пор.

 

А что, неплохой выбор, Nim тоже фичастый.

О_о Не знаю…

 

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

а при чём тут процент? речь-то о скорости операций фс идёт, а морда того же ютуба загружается в бравзер юзвера и катается на его (юзвера) железке.

 

Хм, почему? Я на плюсах пишу драйвера и под винду, и под линукс - зачем откатываться к чистому си?

Ты уже ушёл в сторону: вот тебе пруфы выше - было столько CVE, переписали на безопасном языке (не обязательно на расте) - стало столько. Вон доклад по статистике CVE в программах. С чем ты ещё будешь спорить?
И по скорости фс - в ядре Linux переписали драйвер NVMe с си на раст. И знаешь, что случилось с производительностью? Правильно, ничего: не изменилась ни на процент.

 

Драйвер можно на любом нативном языке написать, если либо отрубить стандартную библиотеку, или сделать/найти стандартную библиотеку над ядерным апи. Раст вполне может в дрова (no_std).

Смысл есть - на старом всратом языке не писать. Даже такой искренне верующий адепт, как Торвальдс, прогнулся))

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

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

 

и ты пишешь драйвер с классами или просто функции?

Ты так и не понял.. реальная защита строится не софтом, а ФИЗИЧЕСКИМ разделением операций == нельзя сломать то, к чему не имеешь ФИЗИЧЕСКОГО доступа.

даже больше скажу - если провести стресс тесты, сыпаться оба дравера будут одинаково

 

С классами, шаблонами, constexpr'aми, с new/delete, с наследованием и самописными коллекциями без исключений.
Можно даже использовать коллекции из STL с оговоркой, что если внутри вылетит эксепшн - получишь багчек.
Вот примеры из Ktl, который делаю на замену Kernel-Bridge'у:


или

--- Сообщение объединено, 4 мар 2023 ---

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