Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 44
Пока разработка ядра Linux занята фигнёй разработка Android перешла на Rust
Дилетантский вопрос. А почему те же С и С++ нельзя сделать безопасными по памяти? Неужели невозможно сделать новую редакцию, совместимую со старым кодом?
Это можно сделать
Боюсь, слишком много способов С++ безопасным - договориться не реально. Новая редакция не нужна, можно что угодно навернуть на одних лишь макросах и ассемблерных вставках.
Технически можно, на практике видимо это сложнее, чем внедрить другой язык.
Ну и были новости что АНБ и иные министерства добра призывали отказываться от C/C++ и переходить на "безопасные" языки.
Можно, в языке с 11 стандарта все есть для безопасной работы с памятью.
Можно, а зачем?
Если компилятор не даст откомпилировать старый, небезопасный код — сломаете обратную совместимость. А если даст, то толку от этого «сделать безопасными»?
Фишка Rust'а в том, что там без unsafe, который обычному программисту не нужен, небезопасный код вообще не скомпилируется.
Фишка Rust'а в том, что там без unsafe, который обычному программисту не нужен, ...
Фишка Rust в том, что некоторые типовые алгоритмы, которые бывают нужны обычному программисту, в принципе невозможно реализовать в концепции владения и заимствования без использования unsafe.
А например?
Хотя я сильно подозреваю, что у нас разное понимание либо «типового алгоритма», либо «обычного программиста». Есть известная статья Степанова с названием типа «ООП не нужен», он там рассказывает, по сути, как заточил язык под удобное написание алгоритмов. Которые обычный программист только вызывает, а пишет раз в год. Что, по-моему, и объясняет, почему обычные программисты с него разбежались кто куда.
А например?
Да легко. В концепции Borrow Checker невозможно множественное владение, игнорируются ошибки, связанные с утечками памяти, а так же нельзя реализовать возможность блокировки объекта на редактирование в нескольких потоках одновременно.
Мы с вами уже это обсуждали, и не один раз. Типовые алгоритмы реализуются один раз, а используются тысячи (а может и миллионы) раз.
Например, ваш любимый двусвязный список, "невозможный в Rust без unsafe" (на самом деле возможный, хотя и не оптимальный) есть даже в std. Зачем обычному программисту реализовывать заново то, что уже кто-то написал?
а так же нельзя реализовать возможность блокировки объекта на редактирование в нескольких потоках одновременно
Звучит очень опасно, не зависимо от языка программирования. Для чего вам такое поведение?
Я отвечал не вам, а @ImagineTables. Что же касается вас, то мы с вами действительно это обсуждали и все аргументы вроде бы уже озвучены.
От того что аргументы уже озвучены, они стали менее актуальными? Ведь вы привели свои аргументы еще раз, почему я не могу?
P.S. Клонов у меня нет.
От повторения ваши аргументы не стали более верными. Если вы заметили, то я прекратил с вами обсуждение еще в прошлой ветке, так как вы не обращаете внимание на факты, которые не соответствуют вашей вере во всемогущество и непогрешимость Rust, а споры о религии меня не интересуют :-)
Такой подход можно развернуть и против вас.
Например, вот в этом комментарии вам прямо пишут, что написать двусвязный список можно без unsafe (с помощью счетчиков ссылок и слабых ссылок). Но нельзя написать оптимальную реализацию без unsafe. Аналогично можно написать и более сложные алгоритмы (например деревья).
Но вы и тогда, и сейчас говорите что это не возможно. А, между тем, больше половины вашей статьи опирается на этот тезис, который очевидно ошибочный. Так кто из нас обратился к религии?
Причем тут "развернуть и против вас"? Я опираюсь на факты, а не риторическими утверждения.
написать двусвязный список можно без unsafe (с помощью счетчиков ссылок и слабых ссылок)
Этот код ничем от отличается от кода на С++ и не дает гарантий безопасного управления памятью, о чем я и писал выше.
Причем тут "развернуть и против вас"? Я опираюсь на факты, а не риторическими утверждения.
В таком случае вам нужно было под той статьей написать дополнение, например что "вы имели ввиду оптимальную реализацию". Но что-то вам помешало принять факты, например вера)
Этот код ничем от отличается от кода на С++ и не дает гарантий безопасного управления памятью, о чем я и писал выше.
Ну да, слабые ссылки в std Rust такие же как в std С++. Но и применяются они крайне редко (я вот ни разу не видел). Вместо них применяют готовые алгоритмы с множественным владением. Как и в С++.
А вот о чем вы умалчиваете: другие виды утечек памяти не возможны, как и use after free. Если вы не используете слабые ссылки, никогда память не утечет.
Лучше какая-то (и очень неплохая) защита на уровне языка, чем никакой.
Вот сейчас было обидно.
P.S. Но вообще, я с @qwerty19106 согласен. Вот в этом вопросе:
Типовые алгоритмы реализуются один раз, а используются тысячи (а может и миллионы) раз.
То есть, у нас с вами действительно разное понимание того, что такое обычный программист. Мне кажется, вы завышаете планку.
Искренне прошу прощения за невольную обиду, так как собеседник очень настойчив в попытке насаждения своей религии, поэтому я и предположил наличие у него нескольких аккаунтов.
Но это ни в коем случае не попытка очернить вас и мне искренне жаль за сделанную ранее формулировку.
«Вот сейчас обидно было» говорят с иронией. Иногда иронично выбирая из списка того, на что можно обидеться, наименее обидное, чтобы создать максимальный комический эффект. Но я такой глубокий смысл не вкладывал, я просто пошутил. На самом деле меня очень трудно обидеть: на свой счёт я стараюсь принимать только деньги.
нельзя реализовать возможность блокировки объекта на редактирование в нескольких потоках одновременно
И это прекрасно
Нельзя. Для таких целей нужно дизайнить язык с нуля. И начинать дизайн этого языка нужно с системны типов, в которойи 100% должны быть а) линейные типы б) констрейнты
Потому, что слишком уж много всего завязано на ручной контроль памяти в существующей кодовой базе. А если ее выкидывать, то такая "совместимость" никому нафиг не нужна. И в итоге все равно получится Rust :)
"Свободный" дизайн языка C (ручное управление памятью, отсутствие проверок в рантайме, алиасинг, свободные касты между указателями и значениями и т.д.) делает верификацию большинства кода на нем невозможной во время компиляции и очень сложной в рантайме.
Про C++ и говорить не приходится, язык настолько сложный, что наверное ни у кого нет полного понимания, как сделать язык безопаснее без поломки обратной совместимости или создания "нового" языка (см. hsutter/cppfront), а стандарт с каждым годом все больше и больше...
Раст же изначально сконструирован так, чтобы всякая синтаксически корректная программа (без unsafe) могла быть формально верифицирована на этапе компиляции, а все массивы имеют проверку границ в рантайме (хотя как я понимаю вся эта безопасность присутствует только на уровне работы с памятью ОС - компилятор не помешает вам написать свой аллокатор поверх массива с индексами вместо адресов и стрельнуть себе в ногу уже с помощью него).
Для Си сейчас появился проект Fil-C, который по факту добавляет в язык рантайм со сборщиком мусора и расчитан на компиляцию всяких программ, в которых можно пожертвовать производительностью в угоду безопасности, но он тоже иногда требует изменений в исходном коде.
Про C++ и говорить не приходится, язык настолько сложный, что наверное ни у кого нет полного понимания, как сделать язык безопаснее без поломки обратной совместимости или создания "нового" языка ...
Это делается точно так же как и в Rust - с помощью статического анализатора кода. У С++ другая проблема - сложно договориться какую концепцию реализовывать (проверять анализатором).
Процедура принятия новых стандартов настолько сложна, а пользователей языка так много, что всегда найдутся недовольные любым предложением. Сейчас даже авторитетов Бьерни Страуструпа и Герба Саттера недостаточно для того, чтобы протащить через комитет профили безопаснсти.
Про C++ и говорить не приходится, язык настолько сложный, что наверное ни у кого нет полного понимания, как сделать язык безопаснее
Все там понятно. Но переписывать придётся.
С нельзя сделать безопасным фундаментально, он не даёт таких инструментов.
А С++ в ядре запрещен. Это хотелка Линуса, и очень давняя. В целом я понимаю почему это было, но почему сейчас - нет. Язык сделал много шагов в сторону безопасности. Но писать на нем безопасный код сложно. Возможно сложнее чем на С.
Вот будет весело, когда пойдет обратное движение по выпиливанию Rust из ядра Linux
Рад что они приняли решение внедрять раст , другое дело что походу там над этим работает полтора дровосека , я очень расстроен. Такой гигантский вклад в сообщество раста и тут же тормоза
Cloudflare уже сломали с помощью Rust-а, теперь хотят Linux и Android сломать. Ничем хорошим эта погоня за хайпом не закончится
На Rust можно писать новую ОС если уж так хочется, зачем его пихать в Linux который десятилетиями делали на С и все было нормально
Чисто логические ошибки можно допустить на любом языке программирования. Мало их на C допускали?
Rust же просто удобнее и снимает часть головной боли с разработчика.
В любом языке можно наломать дров. Сейчас в rast учли старые ошибки, завтра в нем начнутся новые о которых еще никто не знает. Так было и так будет, чем меньше человеку нужно думать тем хуже будет код
Так философия раста прямо обратная тому что вы говорите: его borrow checker, вызывает головную боль при написании, чтобы уменьшить количество головной боли в будущем.
Раст требует от программиста больше думать при написании чем тот же Си, для того чтобы код скомпилировался, в то время как си требует от программиста больше думать чтобы написанный код был безопасным
Cloudflare "сломали" и с помощью Lua, что-то я не слышу призывов выпиливать Lua отовсюду.
Cloudflare падал не из-за языка, а из-за того, что кто-то недальновидно написал не полноценную проверку ошибки, а assert её отсутствия, который очевидно крашнулся в рантайме. К языку ошибка отношения не имеет, только к (удивляющему меня) отсутствию у КФ практики вставлять #[forbid(unwrap_used)] во все новые проекты
Cloudfare сломал не раст, а макака которая буквально в коде объявила throw exception, через unwrap. Это было ее решение, не раста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новый патч для Linux подтверждает: эксперимент с Rust завершён, Rust останется в проекте ядра Linux