ฝัง
- เผยแพร่เมื่อ 8 พ.ค. 2024
- В этом ролике я расскажу о философии unsafe & safe Rust, для чего применяется ключевое слово unsafe.
----------
Поддержать: boosty.to/bitwiseuwu
Мой гитхаб: github.com/IoaNNUwU
----------
Это видео может быть интересно любому, кто интересуется системными языками программирования, любит изучать низкоуровневые концепции и работу железа - процессора, оперативной памяти, видеокарты. Если вы знаете или хотите изучить языки C++, Go, Zig - Rust станет отличным дополнением, а возможно даже сможет сместить ваш интерес в свою сторону за счёт таких преимуществ, как безопасность памяти, потокобезопасность, современный API. Rust так же станет прекрасным языком, если вы хотите лишь немного прикоснуться к системному программированию, изучить работу железа, но при этом не оставлять высокоуровневые, простые в использовании языки, такие как Python, Java, JavaScript, Kotlin, Lua.
На этом канале вы найдёте множество видео как на тему системного программирования, так и более общих концепций программирования, таких как ООП, системный дизайн и множество других тем, которые стоят того, чтобы их обсудить. - วิทยาศาสตร์และเทคโนโลยี
![[TH] 2024 PMSL SEA W3D1 | Summer | เริ่มต้น สัปดาห์ตัดสิน](http://i.ytimg.com/vi/pWsl9LhC2Uk/mqdefault.jpg)
Свежий русскоязычный канал с не хелоуворлд роликами про раст? Однозначно плюс!
не смотря на всеобщую демонетизацию, малый и узкоспециализированный контент переживает настоящий ренессанс
Наверное потому, что ушли те, кто были за деньги, а те, кто делал все для продвижения и просвещения остались... Чисто мое предположение
самое плохое с UB, это когда компилятор может по разному генерить код в зависимости от заданной оптимизации. То же переполнение может нормально работать в дебаг режиме, и перестать работать после релизной компиляции с включенной оптимизацией. Вот ту реально мозг может опухнуть - дебажишь код - всё работает компилишь релизную версию - всё ломается.
Было дело, что при выставлении высокой оптимизации gcc падал с segmentation fault, так до сих пор код на проде и работает с низкой оптимизацией.
а еще веселее, когда автору сего поделия глубоко с высокой колокольни, что его код глючит на -O3 и при этом нормально работает на -O2, хотя часто это кричащий индикатор UB
Спасибо, пересматривал видео несколько раз, приятно слушать и материал проработанный
Хорошее видео, желаю удачи с развитием канала :>
Желаю удачи и набрать много много подписчиков, давай больше нам Rusta❤
Хороший материал, комментарий в поддержку канала
очень круто. если в видео будет больше практики, то будет имба. потому что так лучше понятнее
Это прям круто! Так и продолжай
Где информацию по расте брал? Какой у тебя был бэкграунд до раста?
Интересно было слушать. Как проводятся проверки времени выполнения кода на примерах rust и c. Просто с помощью функций time?
На самом деле пример в видео несколько приукрашен, потому что очень сложно сравнить производительность именно с функцией print, поскольку скорость функции print_el упирается не в доступ к элементам, а в ввод-вывод. А если рассматривать пример без print, то можно просто сравнить сгенерированный ассемблер, например здесь ( godbolt.org/z/1no3oPKzf ) видно что раст генерирует проверки (ну или просто видно, что в раст много больше инструкций) и ассемблер включает вызовы core::panic::panic_bounds_check для проверки доступа, а здесь ( godbolt.org/z/bcTozj3qh ) добавив условие len < 3, мы видим очень похожий список инструкций от обоих языков.
@@bitwiseuwu я мало понимаю в ассемблере и такой низкоуровневой теме, правильно ли просто сказать что там больше кода и поэтому Раст медленнее?
@@user-ml4vl8rk6o Вообще-то больше интрукций не всегда медленнее, скорее надо смотреть на род инструкций, именно условия (инструкции test, cmp, je) замедляют код. Версия раст генерирует эти условия, а С - нет.
@@bitwiseuwu понятно, спасибо
Ооо, маловато в ру комьюнити растеров-ютуберов. Удачи тебе!
12:59 кажется инварианты это другое, не "состояния, в которых структура не может находиться", а скорее наоборот
Почему же, например инвариант структуры NonZeroU32 - это то, что она не находится в состоянии, когда её внутреннее число равно 0. Инвариант мутабельной ссылки - нет такого состояния, когда существует ещё одна. Инварианты структур можно описать именно так, но соглашусь, что определение не полное и инварианты - это также правила для отдельных unsafe функций. Тут я скорее пытаюсь объяснить происхождение слова инвариант - то есть не вариант - вариант, который не принимает структура.
инвариант структуры это набор корректных состояний, в которых она может находиться.
2:44 Это с какими опциями оптимизации надо компилировать для такого результата!?
Если честно, в rust такого накрутили, что порой элементарные алгоритмы не получается реализовать недельного курения материалов
отличное видео
Здравствуйте, подскажите что делать изучал раст знаю времена жизни почти полностью прочитал раст бук(дальше вряд ли буду читать там уже по мелоче) Стоит ли продолжать писать на расте мне 14 лет, системное программирование не интересует от слова совсем. Посоветуйте что-то пожалуйста, буду рад ответу!
если системное программирование не интересует, то не стоит, тем более на расте практически невозможно найти работу, а если и можно, то там только блокчейн; короче, лучше потратить время на более реалистичный язык.
@@mister-ace мне еще до работы 5-6 лет учиться.
Идёшь изучать тайпскрипт, а после если осилишь переключаешься на цпп. В тс много концепций из цпп, либо похожих на цпп.
Я думаю, что для устройства на работу реалистичнее учить например Go, работу на нём можно найти даже в крупных российских компаниях, а знать надо не очень много. Знания Rust если не позволят устроиться на работу, то прокачают понимание работы железа, что будет явным преимуществом при трудоустройстве. Так же непонятно где будет Rust через 5-6 лет - возможно и не будет такой проблемой устроиться.
@@bitwiseuwu Можешь мне рассказать каким образом раст связан с железом, если он в принципе никакого отношения к железу не имеет и собирается через цпп-компилятор и работает в рамках цппешной виртуальной машины. Как там в параллельной вселенной?
Уж если говорить про железо, то го куда ближе к железу. Потому что имеет прямую с ним связь, свою модель исполнения, свой компилятор и прочую атрибутику того что имеет связь с железом в реальности, а не фантазиях.
Подписался. Пили ещё видео по расту 👍
Как насчёт видео про async/await?
Обязательно будет! Но думаю сначала стоит сделать ролики по базовым концепциям, чтобы не сломать людям голову
А я не любитель раста!!! Я любитель Си!!! Послушай песенку "write in C", советую тебе
P.s (коммент для продвижения видео, написать просто что-то надо)
👍👍👍
Крутой видос!
Что-то со звуком, в произношении есть посторонние частоты которые бьют в перепонку уха.
Internal mutability еще есть. Почему он существует? Почему не unsafe вместо него?
Обязательно будет про это видео, на самом деле interior mutability - это красивое название для обхода ограничений языка с помощью unsafe кода.
Приветствую всех сектантов секты Rust! 😀😃
Подпишусь для кол-ва, буду посматривать, в чем смысл раст
А будет как вызвать UB в safe Rust?)))
Это запретная тема, поэтому будем её игнорировать
@@bitwiseuwu А кто запретил?) Мне кажется, кто номикон читал, этим уже не напугаешь. Не зря там большой алерт перед чтением весит, что ваша жизнь не будет прежней 😁
Нее. В расте нет UB!! И в ансейфе нет UB больше чем в си!! (Сарказм)
В своей сфере Red Team & Malware development вижу что многие пытаются на расте что то писать. Выглядит отвратительно. Почти весь код в unsafe блоке. Очень многие вещи нельзя сделать. Например я не знаю как в расте заставить положить всю строку на стек(не указатель, а именно весь массив). Вместо того чтобы в .rdata ее располагать. Метапрограммирование и compile time в расте гораздо хуже развито. Я не могу очень многие вещи сделать которые на Плюсах делаются через различные трюки.
Раст хорош пока он safe rust. С небольшими выходами на unsafe. Но когда у тебя 90% в unsafe. Стоит задуматься об использовании гораздо более удобного, понимаемого и дающего больший контроль языка, Си или плюсы. Писать Windows kernel Mode драйвер на раста это глупость.
Что значит "меньше развито"? Его там в принципе не существуют как и системы типов, которая осталась где-то в доисторической эпохе несмотря на тысячи костылей. Всё это обычно путают с макроснёй неотлаживаемой томрозной и всегда неработающий.
А в safe rust, хотя такой существует только в головах понятно кого, всё ещё хуже. Рескин сишки еле-еле позволяет байты месить на базовом уровне(дальше этого мало кто ушёл), а вот дальше большие проблемы.
Да и писать какие-нибудь круды проще чем лоулевел потому что это круды, а не потому что раст/иной язык. Хотя о выразительной способности ходят легенды.
Rust на практике решает проблему UB за счет производительности и использования памяти, попробуйте сделать универсальную структуру дерева (TreeNode) :либо Rc либо арена. Может когда-нибудь они допилят борроу чекер, но сегодня его строгость - большая проблема. По моему лучшим решением было бы решать проблемы UB в режиме отладки, с возможностью отладчика выявлять опасные места. По такой концепции идет zig, но он еще очень сырой, и вроде как есть специальные аллокаторы и методики для c/c++, а раст - это огромная плата за безопасность сложностью и производительностью.
Я согласен, но уверен, что многие предпочтут именно отсутствие UB любой ценой, тем более такая ли высокая цена по производительности? Это надо смотреть в каждом отдельном случае. А насчёт сложности я считаю, что использовать Rc проще, чем в ручную заниматься менеджментом всех указателей, ведь в случае ошибки мы получим панику, а не UB. На самом деле иногда Borrow Checker только мешает, деревья - отличный пример, ведь добиться множественного владения в Rust не просто, в связи с этим возникает мысль о том, что следует развивать unsafe Rust, чтобы он мог стать альтернативой Zig. Но я всё же остановлюсь на том, что далеко не весь код состоит из деревьев и жертвовать безопасностью в остальных сферах из-за нескольких неудачных мест не хотелось бы.
Для того, чтобы писать базовые структуры данных по типу деревьев и прочих коллекций - нужен unsafe. Это не баг, а фича. Так ты с одной стороны получаешь минимальный оверхед, а с другой стороны полностью safe публичный api, благодаря которому ты можешь использовать свою структуру данных не парясь на счёт UB и без необходимости дебажить каждый новый код, написанный с твои деревом. Это намного проще, так как большая часть прикладного кода спокойно пишется полностью без unsafe-а.
Да, придётся запариться и написать структуру данных и хорошо её протестировать, чтобы ансейфти никуда не утекло. Так что без своего любимого отладчика никуда не денешься
И ещё, зачем тебе Box внутри Rc? Это бесполезная двойная косвенность. Rc уже проще. К тому же, честно говоря, RefCell на практике реально нужен очень редко. Та же арена куда более лучшее решение
@@nanoqsh dyn any имеет неизвестный размер во время компиляции, поэтому только RefCell - это же азбука раста, стыдно не знать. А без refcell ничего не выйдет, т.к ссылка на ноду уже есть в другой ноде, без refcell весь смысл пропадает. Арена это тоже не так просто, когда дойдет до итерации по дочерним узлам, получается очень тормозная штука, раз в 10 медленнее чем тоже самое на любом другом языке, включая java и go.
@@bitwiseuwu UB согласен, но раст ведь дает не единственно возможный способ избежать UB. В попытке разобраться с этим borrowchecker я добрался до трейтов DispatchFromDyn и CoerceUnsized, и после этого как-то подостыл к расту. Неоправданно большие трудозатраты для борьбы с borrowchecker-ом. Проблема UB должна решаться другим способом, например отслеживанием узких мест во время отладки.
а как быть с тем что 70% опытных сотрудников потом исправляют свои ошибки? и в 99% случаев не пишут код с первого раза верно?
лол. к нам менеджер пробрался?
@@zerdox4 может быть да может быть нет....
Враньё про уб на примере функции с переполнением из раст-методички. Если твои вычисления с интами где-то переполняются, то смысла в твоих вычислениях нет - они неправильные. Поэтому ссылаться на то что какое-то уб что-то там делает. Никакого уб там нет, а просто банальный вывод. Ты всегда предполагаешь что твои вычисления не переполняются, если они выдают корректный результат. А уж то, что стандарт не определяет связано именно с этим в основном, а уже во вторую очередь с оптимизациями, переносимостью и прочим. Просто, опять же, невежество и ретрансляция поверий из интернета.
Вообще ничего не понял, но видно, что автор разбирается в теме
😭А что помешало понять? Я предполагаю, что непонятно будет тем, кто вообще незнаком с языком Rust и не представляет что это за язык. Я стараюсь делать так, чтобы понятно было тем, кто хоть что-то слышал о системных языках и игрался с самим Rust. Может сделать видео типа «Что такое Rust», но мне казалось, что заинтересованные уже давно прознали про этот язык.
@@bitwiseuwu я не знаком с rust, думал видео будет больше на новичков рассчитано, но видимо, расчет на опытных пользователей, что тоже хорошо, такие видео тоже нужны. Видео про «Что такое Rust» я бы с радостью глянул от знающего человека, вы явно разбираетесь в теме.
@@bitwiseuwu привет) я работаю джуном на TS, но интересуюсь другими языками, так что какое-нибудь лёгкое видео по типу что такое Раст было бы интересно)
то что синтаксис доступа к индексу массива паникует по дефолту - огромный минус. это должен быть Option или Result. либо вообще отказываться от этого синтаксиса и написать функцию которая может вызвать панику при доступе. паника не должна вызываться неявно с помощью языковых конструкций
Он не паникует по дефолту. Просто у тебя программа падает везде и всегда. Никакой option/result он быть не может потому что это мусор. Как ты далее сделаешь выражение с этим доступом? `arr[x] + y`? Никак. Да и вообще рассуждать о чём-то в контекста раста не имеет смысла. Всё это сделано чтобы врать, а не чтобы этим пользоваться. Ну и да, стоит не забывать что если бы цпп делал тоже самое, то это бы не считалось и было бы проблемой.
Для массивов существует специальная функция .get(index), которая возвращает Option. Паника по дефолту - это на мой взгляд вполне хороший подход, ведь выход за границы массива - это наверняка баг, поэтому делать явным обработку бага было бы странно.
@@tgitw-tq6iu Я вот не пойму, это шутка или ты просто решил комментариев накрутить?
@@bitwiseuwu push в вектор тоже баг?
@@bitwiseuwu я прекрасно знаю про .get(index). Про панику по дефолту - не соглашусь, вызывающий вашу функцию и программу должен всегда знать на уровне типов где и как она может зафейлится. В случае паники он просто может не знать что ему с этим делать. Ведет к потере информации и невозможности автоматически ее обработать. Это особенно критично когда вы используете ffi и не пишите на расте сами. Плюс паника в цикле может вести к потере информации при тяжелых вычислениях. Одна паника - и все вычисление коту под хвост
Эта смесь невежества и обрывков определений. Уб существуют в си не из-за оптимизаций, не из-за "нелепых случаев" и прочих фантазий, а из простого факта. Стандарт не может определять поведение для всех возможных случаев. Точно так же как какая-нибудь скорость света определяется в вакууме, а всё остальное уб. Определению и ненужно определять её во всех возможных средах.
Ну это же просто неправильно. Стандарт на то и стандарт, что именно он определяет поведение языка и сделать он может это для всех возможных случаев, но специально часть случаев упускает. Компиляторы подстраивают свою реализацию под этот стандарт, не существует какого-то "факта" неопределённого поведения.
@@bitwiseuwu Хорошо, если для языка нужен стандарт, который определяет всё - где стандарт для раста? Получается любая строчка кода на расте УБ ведь там нет определения из стандарта.
К тому же зачем ты что-то пишешь, если ничего не понимаешь? Стандарт в принципе не способен определять поведение - это невозможно. Как невозможно определить скорость света для всех сред о чём тебе сказали выше.
Никакой раст не решает никакую проблему. Тебя обманули. Раст не допускает УБ потому что он находится вне области определения этого понятия.
Лучше уж рисковать, наткнутся на неопределённое поведение, через кровь пот и слезы найти ошибку, но зато больше его не допускать, чем позволить компилятору языка решать за тебя, какое поведение лучше.
Легко сказать «больше не допускать», это ведь не так прост, тем-более в случае с UB можно даже никогда не узнать, что оно присутствует. А компилятор раст просто делает обязательным то, что в C++ считается очень хорошей практикой - а именно чёткая модель владения.
@@bitwiseuwu Я думаю если проблема присутствует, то программист должен её видеть при тестирований. Я понимаю в чём недостатки подхода возложить всё на программиста, но не могу не могу игнорировать его плюсы.
@@anonsd5521 аниме на аве - мать в UB канаве
Никакое условие if не сравнивает производительность кода. Ты врёшь. Даже если там что-то сравнялось это просто следствие того что оптимизатор цпп-компилятора смог убрать проверки. Но работает это только в примитивных примерах. К расту никакого отношения не имеет. К тому же такой код никто не пишет.
Далее он опять врёт о том что нужен язык си для взаимодействия с ОС. Никакой язык си ненужен для взаимодействия с ОС. Си просто может с ней взаимодействовать, а ты нет. И поэтому ты используешь си. Как и жава. И чтобы оправдать свою неспособность ты врёшь. Из этой чуши не следует существование ансейфа.
Ансейф существует только потому что никакого сейф-раста и гарантий фентезийных тоже. Это не полноценный язык даже по меркам жаваскрипта. Поэтому его область применения крайней ограничена и на самом деле неявно вызывает тысячи ансейф-кода(да, да написанного на расте). Примерно точно так же как питон.
А т.к. это пастве знать необязательно создаются легенды про "нужно си для ОС", "нужен ансейф для какой-то лоулевел работы". Всё это враньё.
Врёт про "причина всегда в ансейф-блоке". Это, мало того, что не имеет смысла. Ведь причина чего-либо всегда в коде, который написан снизу, а не сверху. А враньё это не поэтому, а потому что никакой баг никогда в ансейф-блока не ищется. Просто данный персонаж скрипторебёнок, который ничего не знает. Проблема как раз таки в окружающем коде и том как разные блоки взаимодействуют друг с другом. Инвариант существуют в коде выше и в том как ты его вызываешь, а не в блоке. Здесь он тоже наврал. И эти нарушения ищутся в коде выше, а не в блоке.
Опять враньё про панику. То, что паника сделана поверх ворованных у цпп-компилятора исключениях(потому что раст собирается цпп-компилятором) это не означает возможность восстановится. Исключения нужно не просто украсть, а реализовать код таким образом чтобы он был корректен. Никакой раст код не является таковым. Аналогично паника ничем не отличается от УБ. Во-первых потому что паника уже УБ просто это понятие не определяется. Ты так же не знаешь кода и где твоя паника вылетит и что произойдёт с программой. Да и работает она просто потому, что раст собирается конкретным цпп-компиляторов для которого всё это не является УБ. Вообще применение этого понятия к расту некорректно. И всё состояние твоей программы после паники УБ в отличии от цпп после исключения. Опять же если код безопасен для исключения, а цпп он безопасен, а в расте нет.
Какой же клоун на 18минуте рассказывающий про какие-то инварианты в ансейфе и то, что это не си. Да, это не си. Потому как си в 10раз надёжнее. 70% дыр в расте связано не си и не с фетезийными уб, а с самим растом. Здесь он просто бездумно повторяет какие-то лозунги. Раст не отслеживает чтения/записи. Там уб. Об этом написано даже в документации, а именно:
let x: i32 = unsafe { MaybeUninit::uninit().assume_init() }; // undefined behavior!
Если удалить код с for никакой ошибки не будет и будет уб. Потому что ансейф всегда уб и ничего не проверяет. И уб здесь даже не потому что си, а потому что раст.
Ансейф полностью выключает все проверки. Здесь опять автор повторяет старые мантры. Самое смешное, что буквально несколько секунд назад он это демонстрировал. Опять врёт про какую-то ОС, которая использует какой-то язык си. Никакой ос не использует язык си.
И того. 22 минуты вранья. Я не увидел даже минимально-адекватных лозунгов.
Уже спустя 20 секунды ты соврал. Никакой раст не гарантирует отсутствие уб в сейф-коде. Далее ещё раз соврал. Уб понятие стандарта си. Какое отношение он имеет красту? Какое поведение раста определено в стандарте си? Никакое
В мс не работают лучшие программисты. Откуда ты взял такую глупость? Статистика от конъюнктурщиков ничего не стоит. Никаких 70% там нет это всё враньё. Эта заявления ни на чём не основаны и пруфов никаких нет. Я тебе могу хоть 100% вывести потому что любая ошибка в принципе по определению связана с памятью. А знаешь почему? Потому что программа всё что и делает - это месит память. Там даже не про ошибки написано, а про ошибки безопасности. Но, опять же, все ошибки связаны с памятью. По определению.
Вы своей ржавчиной колетесь для того чтобы обколовшись выкинуть из языка единственное полезное что в нём было - безопасность памяти - чтобы теперь уже и колоться и ронять память?
раст это шутка, раст для идиотов написал кто-то