Відео

Классная картинка, но нужен углублëнный rust

С одной стороны хорошо, что автор в конечном счёте предлагает опираться не на туманную терминологию, которую, как видно из комментариев, многие понимают по-разному, что делает её не эффективной в плане передачи идей (независимо от того, чья это вина), а предлагает вместо этого смотреть на суть и на конкретику, анализировать реальный случай / задачу. С другой стороны, есть пара моментов, которые считаю нужным озвучить. Во-первых, утверждение, что enum не влияет на скорость работы - ложное. Если в коллекции будут неким случайным образом чередоваться типы, branch prediction будет постоянно лажать, что в свою очередь будет приводить к потере многих циклов. Кроме того, если для разных типов операция, выполняемая в цикле, потребует разных по объёму данных, то либо они будут храниться по ссылке, что будет приводить к промахам кэша, и опять потере многих циклов, либо элементы в списке будут занимать наибольший размер из задействованных вариантов, что также означает неэффективное использование кэша процессора. На эту тему можно посмотреть ставшее уже классическим ua-cam.com/video/rX0ItVEVjHc/v-deo.html Во-вторых, пример с выводом на экран адреса - это плохой пример, т.к. вероятность, что адрес с портом действительно должен выводиться так же, как адрес без порта, я бы оценил как маловероятную, скорее всего это ошибка. И хоть можно подобрать правильный пример для иллюстрации, то что плохой пример просочился в видео разбор, на мой взгляд, наглядно иллюстрирует, что нарушения Liskov substitution principle повсеместны, то есть так уж выходит, что подход с абстрактными типами / обобщённым программированием часто генерирует проблемы (тут можно проводить отдельные психологические исследования, что за дефект в нашем человеческом мышлении к этому приводит, а можно просто принять как данность), а значит неплохо бы задуматься - а стоит эта кажущееся "упрощение" кода того, чтобы повышать вероятность ошибок, которые будут накапливаться и создавать скрытые проблемы в проекте по мере его роста, пока в один день не выстрелят в ногу разработчикам?

Капец тут ебалда в комментах разбушевалась))) Так гореть начал, что накатал 5+ разных комментов)))

Очень годно на самом деле. Молодец!

Несколько правок: 6:40 - В C++ присутствует unique_ptr - аналог Box в Rust. Он позволяет автоматически очищать память, поэтому Box эквивалентен именно unique_ptr. Однако пример в видео скорее про то, что в С++ самый очевидный способ аллоцировать что-либо в куче является небезопасным, а сам unique_ptr требует особого обращения, когда в языке Rust структура Box подчиняется обычным правилам владения, как и все остальные структуры, поэтому автоматический менеджмент памяти происходит по умолчанию. Спасибо @user-nf8zb4qp6j и @8Johnny8Catsvill8 за замечание.

Несколько правок: 16:08 - Как отметил @nikita_x44 - такой способ - это undefined behavior, его нужно заменить на core::slice::from_raw_parts_mut. В следующем видео (Философия unsafe Rust) объясняю, в чём проблема.

Несколько правок: 0:40 - это конечно же C++ 1:28 - правильнее было бы использовать в структуре IpAddrWithPort структуру IpAddr в качестве первого поля вместо a, b, c, d, как я это делаю в примере с языком Kotlin. Некоторые в комментариях говорят, что такой каст вызывает undefined behavior, но формального доказательства никто не предоставил. Компиляторы clang, gcc, msvs выдают ожидаемый результат. Но к счастью это не так важно для темы ролика. 15:50 - я всё же решил сделать бенчмарки для этого примера, чтобы вопросов точно не осталось github.com/IoaNNUwU/poly-bench. Результат - enum быстрее динамического кода в 2, а иногда и в 6 раз. Так же в примере вы можете увидеть как я реализовал удобный публичный интерфейс (enum - часть реализации, поэтому он приватный, пользователь взаимодействует с абстрактной структурой).

👍

Абсолютно некорректный пример из С++, я такой же могу и на расте написать. Использование new/delete в современном C++ это моветон, вы не должны их использовать, если от вас не требуется залезать в "кишки" языка, например если вы реализуете свою собственную реализацию стандартной библиотеки С++. Т.е. обычные программисты должны использовать std::array, std::unique_ptr и т.д., но нельзя использовать new. Некоторые библиотеки типа Qt могут требовать использование new, но они сами управляют памятью. В общем такой себе пример, лучше бы взяли в прмер язык C, где действительно с этим была проблема, а С++ в этом плане такой же безопасный как и Rust.

Есть нюанс: в языке Си нет ссылок

кстати сейчас проверил как работает с enum. и как будто бы на скорость не повлияло вообще

Что-то у автора/спорщиков проблемы с реализациями рассказав о том как они приведут енамы к удобному/расширяемому виду. Вот самый простой пример godbolt z/En1Tjs1qM - того что должно получится.

Полиморфизм это когда кролики от одной пары в разной среде разные.

1:28 - UB, нарушение правил алиасинга

В print_addr можно засунуть любую ссылку на объект содержащий struct IpAddr если ты не боишься неопределенного поведения, потомучто в си указатели на два разных типа данных не могу ссылаться на одну и туже область памяти. Type punning который ты показываешь является строго говоря не очень хорошей практикой, особенно если ты захочешь за оптимизировать код ударившись в параметры компиляции.

Как много знатоков собралось в коментариях

на сколько избыточных шагов готовы фанатики, чтобы не писать обычные ifы

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

на 15:10 автор начинает фантазировать на тему про какие-то "интфрейсы" поверх енумов не показывая код. Такое не реализуется. Поэтому ты либо берёшь сишный енам и пишешь в каждом месте свич с копипастой(без полиморфизма), либо берёшь vtable со всеми её проблемами.

фантазии автора на 14:00 демонстрируют ту проблему о которой я писал ранее. Автор берёт раст и тот факт, что там "статический" полиморфизм является таким же динамическим и делает вывод "мы можем заменить". Нет, ты можешь заменить именно потому реализация примитивна. Именно потому что язык не имеет нормальной поддержки полиморфизма. В языках с мощным динамическим/статическим полиморфизмом одно нельзя свести к другому. В языке, где полиморфизм одно название семантически динамическое и немного с монорфизацией, немного с интанцированием сигнатур. Там да - разницы нет, повторяю. Но это свойство немощности языка и реализации, а не полиморфизма. Это не значит что статический/динамический полиморфизм ~одно и тоже.

Рассуждения автора про классификацию полиморфизмов является глупостью полной с попыткой подбить реальность под свои "язык" и свои представления. В реальности существуют два типа полиморфизма - полный и табличный. И табличный действительно не зависит от реализации. Неважно есть там виртуальный вызов или нет - это не меняет поведение. Это та самая ничего не значащая деталь. Причём автор каким-то образом называет енам динамическим полиморфизм хотя он им не является. Это вообще не полиморфизм. В нём ты обязан написать код для каждого из типов. Но частично такое можно назвать таблицей просто написанной руками в каждом месте использования. Настоящий полиморфизм или всякие его ограниченные попытки его реализовать типа высокородный/hkt. Он статический. Именно потому что типы разрешают статически. Там ненужно никаких таблиц. Ненужно никаких ограничений на один интерфейс. На один тип. В какой-то мере он более общая вариация структурного, но структурный полиморфизм вообще не полиморфизм. Он про то каким образом происходит тайпчекинг. Есть самая тупая реализация - через "наследование" как это происходит в жаве/расте/практически везде. Эта реализация максимально примитивна и потому популярна. А так же максимально тормозная и ограниченный. Структурный полиморфизм это про структурный тайпчекинг, который проверяет то соответствует ли контекст использования используемому типу. Это куда сложнее. Требует более мощной системы типов и тайпчекинга. Немощные языки типа раста в это принципиально не могут. Такой полиморфизм часто встречается в динамических языках потому что тайпчекинг там динамический и реализация этого не особо сложнее "наследования". Но в рамках статического тайпчекинга это очень редкое явление существующие разве что в цпп в степени достаточно для использования.

на 10:00 автор наконец-то смог сообщить о проблеме, которая присуща енаму убогому. Особенно в том как он реализован в расте. И анам так же тормозит. И я уже подумал что автор чекнул своё невежество, но нет. Он начал рассказывать истории про "вы пишите код для себя". Я понимаю, конечно, что кроме лаб "для себя" на расте действительно ничего не пишут и написать в принципе не очень реально, но всё же. Если я пишу код для себя мне что ненужно его расширять/изменять? Мне ненужно добавлять новые фигуры? Или ты хочешь чтобы я руками в 1000 местах менял эти свичи? В этом проблема. В том, что этот свич нужно писать в каждом месте, где используется енам. Кстати, не помогут здесь и всякие сказки с сообщениями об ошибке, потому что почти все свичи который я видел в расте содержат _, а значит когда ты добавишь новый элемент у тебя просто даже сообщений об ошибках не будет. И в случае что-то в рантайме упадёт.

8:11 - очередное враньё про цпп и то, что "суть одна" "одинаковый набор методов". Нет. Здесь автор пытается навязать ограничения примитивной раст-реализации на остальные реализации. Остальные умеют наследование, множественное наследование, виртуальное наследование rtti с приведением по иерархии. В каких-нибудь жавах есть рефлексия. Реализация раст просто самый примитивный костыльный костыль из бородатых годов, которая каким-то образом приравнивается к другим с навязыванием им тех же свойств/ограничений.

Выдал базу, шикарный ролик. Но почти каждый, кто изучил раст, знает хотя бы примерно об этой теме. Хотелось бы кстати ролик про crates, rust без cargo или еще что-нибудь подобное

5:50 - полиморфизм с генериками в расте не имеет никакого отношения к статического полиморфизму. Это семантически тот же динамический полиморфизм, но с монорфизацией. А генерики там используются совершенно для иного. Далее пошла какая-то чушь про "максимальную скорость" ни к какой скорости отношения это не имеет. Оно там всё максимально тормозное. Самое смешное тут то, что автор говорит "нам неважно что draw", но что изменилось? Генерикам важно что draw? Нет, неважно. Ничего не меняется. Здесь проблема того как засунуть всё это в один вектор, а не в том что и как вызывает и что и кому важно. Поэтому нужно помазать боксингом.

4:14 Нет, никакой раст ничего не знает об оптимизациях и функциях. Очередное враньё. Почему там прикрутили монорфизацию я сообщил ранее. Зачем монорфизация нужна в языках без боксинга? Ответ очень прост и не связан с той чушью, что автор вещает. Есть проще, то процессор не знает ничего про полиморфизм и прочие сказки. Весь код должен быть мономорфен. Если есть два разных типа - ты либо делаешь 2 разных функции, либо приводишь эти два типа к одному внутреннему типу(что и является боксингом).

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

Удивительно как манипуляции и невежество порождают фичу из дыры. Интерфейсы, а не данные там существуют по той причине что реализовать их в 10раз проще, а не из-за твоих фантазий и придуманных задним числом историй. В примере с си(в котором почему-то оказалась ссылка) вообще враньё. Потому что никакие имена полей как и дополнительные поля ни на что не влияет. Там влияет только расположение данных в памяти. Наследование используется только по одной причине - его реализовать в 100 раз проще чем структурный полиморфизм(пример которого ты даже не показал. В си это не структурный полиморфизм).

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

Approved by true Rust patriot

крутой ролик, спасибо!

Ого. Спасибо за старания. Очень интересно получилось

очень круто, спасибо. как раз в своем проекте использовал динамичиский тип, при этом у меня еще объект помещен в OnceCell, думаю попробовать переписать на enum.