С одной стороны хорошо, что автор в конечном счёте предлагает опираться не на туманную терминологию, которую, как видно из комментариев, многие понимают по-разному, что делает её не эффективной в плане передачи идей (независимо от того, чья это вина), а предлагает вместо этого смотреть на суть и на конкретику, анализировать реальный случай / задачу. С другой стороны, есть пара моментов, которые считаю нужным озвучить. Во-первых, утверждение, что enum не влияет на скорость работы - ложное. Если в коллекции будут неким случайным образом чередоваться типы, branch prediction будет постоянно лажать, что в свою очередь будет приводить к потере многих циклов. Кроме того, если для разных типов операция, выполняемая в цикле, потребует разных по объёму данных, то либо они будут храниться по ссылке, что будет приводить к промахам кэша, и опять потере многих циклов, либо элементы в списке будут занимать наибольший размер из задействованных вариантов, что также означает неэффективное использование кэша процессора. На эту тему можно посмотреть ставшее уже классическим kzitem.info/news/bejne/045mr6iMfoibe5g Во-вторых, пример с выводом на экран адреса - это плохой пример, т.к. вероятность, что адрес с портом действительно должен выводиться так же, как адрес без порта, я бы оценил как маловероятную, скорее всего это ошибка. И хоть можно подобрать правильный пример для иллюстрации, то что плохой пример просочился в видео разбор, на мой взгляд, наглядно иллюстрирует, что нарушения Liskov substitution principle повсеместны, то есть так уж выходит, что подход с абстрактными типами / обобщённым программированием часто генерирует проблемы (тут можно проводить отдельные психологические исследования, что за дефект в нашем человеческом мышлении к этому приводит, а можно просто принять как данность), а значит неплохо бы задуматься - а стоит эта кажущееся "упрощение" кода того, чтобы повышать вероятность ошибок, которые будут накапливаться и создавать скрытые проблемы в проекте по мере его роста, пока в один день не выстрелят в ногу разработчикам?
@timurgaliev1162
8 күн бұрын
Капец тут ебалда в комментах разбушевалась))) Так гореть начал, что накатал 5+ разных комментов)))
@Thesinter1
8 күн бұрын
Очень годно на самом деле. Молодец!
@bitwiseuwu
9 күн бұрын
Несколько правок: 6:40 - В C++ присутствует unique_ptr - аналог Box в Rust. Он позволяет автоматически очищать память, поэтому Box эквивалентен именно unique_ptr. Однако пример в видео скорее про то, что в С++ самый очевидный способ аллоцировать что-либо в куче является небезопасным, а сам unique_ptr требует особого обращения, когда в языке Rust структура Box подчиняется обычным правилам владения, как и все остальные структуры, поэтому автоматический менеджмент памяти происходит по умолчанию. Спасибо @user-nf8zb4qp6j и @8Johnny8Catsvill8 за замечание.
@bitwiseuwu
9 күн бұрын
Несколько правок: 16:08 - Как отметил @nikita_x44 - такой способ - это undefined behavior, его нужно заменить на core::slice::from_raw_parts_mut. В следующем видео (Философия unsafe Rust) объясняю, в чём проблема.
@bitwiseuwu
9 күн бұрын
Несколько правок: 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 - часть реализации, поэтому он приватный, пользователь взаимодействует с абстрактной структурой).
@B1TLotus
9 күн бұрын
👍
@AlexAlex-jk2tn
9 күн бұрын
Абсолютно некорректный пример из С++, я такой же могу и на расте написать. Использование new/delete в современном C++ это моветон, вы не должны их использовать, если от вас не требуется залезать в "кишки" языка, например если вы реализуете свою собственную реализацию стандартной библиотеки С++. Т.е. обычные программисты должны использовать std::array, std::unique_ptr и т.д., но нельзя использовать new. Некоторые библиотеки типа Qt могут требовать использование new, но они сами управляют памятью. В общем такой себе пример, лучше бы взяли в прмер язык C, где действительно с этим была проблема, а С++ в этом плане такой же безопасный как и Rust.
@cyrilanisimov
9 күн бұрын
Есть нюанс: в языке Си нет ссылок
@white5493
9 күн бұрын
кстати сейчас проверил как работает с enum. и как будто бы на скорость не повлияло вообще
@bitwiseuwu
9 күн бұрын
Добавил в описание бенчмарки для примера из видео: github.com/IoaNNUwU/poly-bench
@white5493
7 күн бұрын
@@bitwiseuwu спасибо. кажется у меня просто функция выполняется дольше, чем получаемый прирост
@tgitw-tq6iu
9 күн бұрын
Что-то у автора/спорщиков проблемы с реализациями рассказав о том как они приведут енамы к удобному/расширяемому виду. Вот самый простой пример godbolt z/En1Tjs1qM - того что должно получится.
@bitwiseuwu
9 күн бұрын
Спасибо за комментарий, действительно интересно было взглянуть как в современном C++ выглядят енамы. Однако синтаксис на мой взгляд оставляет желать лучшего, потому что приходится использовать темплейты и std::visit для генерации нужного варианта. В Rust это выглядит гораздо более привлекательно и работает с той же скоростью, пример вместе с бенчмарками можно найти на моём GitHub: github.com/IoaNNUwU/poly-bench . Интересно услышать мнение опытного C++ разработчика про синтаксис языка Rust, неужели синтаксис С++ для тех же енамов всех устраивает?
@user-qt5hy3vn5p
8 күн бұрын
Всю глубину уродства этого высера не описать словами...
@user-jv1fy1bz2t
10 күн бұрын
Полиморфизм это когда кролики от одной пары в разной среде разные.
@mishamiskin9159
10 күн бұрын
1:28 - UB, нарушение правил алиасинга
@tgitw-tq6iu
9 күн бұрын
Зачем в портки надул?
@bitwiseuwu
9 күн бұрын
Будет ли? Ведь тут нет разных указателей на одну и ту же структуру, а указатель на IpAddrWithPort должен быть валидным указателем на её первое поле, а поля должны находиться в порядке декларации, значит указатель на IpAddrWithPort будет валидным указателем на IpAddr
@miffop
10 күн бұрын
В print_addr можно засунуть любую ссылку на объект содержащий struct IpAddr если ты не боишься неопределенного поведения, потомучто в си указатели на два разных типа данных не могу ссылаться на одну и туже область памяти. Type punning который ты показываешь является строго говоря не очень хорошей практикой, особенно если ты захочешь за оптимизировать код ударившись в параметры компиляции.
@tgitw-tq6iu
10 күн бұрын
Какие-то фантазии про два типа уровня "слышал про стрикт алиасинк и давай наплету какой-то чуши". Является базовой практикой. Захочу и что же будет? Ничего. Всё как раз таки наоборот.
@miffop
9 күн бұрын
@@tgitw-tq6iu type punning может приводить к багам, когда компилятор думает что ты ссылается на разные области памяти и может поменять порядок выполнения команд над ними
@tgitw-tq6iu
9 күн бұрын
@@miffop Что-то кроме фантазий будет?
@user-bh2ot5ks8f
10 күн бұрын
Как много знатоков собралось в коментариях
@uipo1122
10 күн бұрын
на сколько избыточных шагов готовы фанатики, чтобы не писать обычные ifы
@gepron1x
10 күн бұрын
Без полиморфизма твои ифы будут разрастаться в коде экспонинцеально)
@uipo1122
10 күн бұрын
@@gepron1x экспоненциально по отношению к чему?
@tgitw-tq6iu
10 күн бұрын
Ну этот убогий сахарок ничем от ифов не отличается. Это они и есть только менее мощные. Но проблема с ифами никуда не уходит. Тебе нужно каждый раз руками писать лапшу в каждом месте использования, которая на 90% состоит из копипасты. А при добавление/изменении чего-либо нужно всю это копипасту менять.
@uipo1122
10 күн бұрын
@@tgitw-tq6iu это не проблема с ифами, это фундаментальная проблема растущей сложности, которая не решается каким-то магическим инструментом внутри языка программирования
@tgitw-tq6iu
10 күн бұрын
@@uipo1122 Решается. Это проблема именно ифов и подобного дизайна.
@tgitw-tq6iu
10 күн бұрын
кстати, комбинация настоящего полиморфизма и структурной типизации позволяет писать код быстрее енума с расширяемостью лучшей, нежели в том что автор называет дин-полиморфизмом. Именно поэтому цпп может, а раст нет.
@user-qt5hy3vn5p
8 күн бұрын
Что дцпп может? Судя по количеству бредовых здесь комментариев, дцпп даже работу не может тебе помочь найти
@tgitw-tq6iu
10 күн бұрын
на 15:10 автор начинает фантазировать на тему про какие-то "интфрейсы" поверх енумов не показывая код. Такое не реализуется. Поэтому ты либо берёшь сишный енам и пишешь в каждом месте свич с копипастой(без полиморфизма), либо берёшь vtable со всеми её проблемами.
@miffop
10 күн бұрын
Ну в принципе это возможно, если мы допустим что в у языка с фичей превращения интерфейсов в энамы не будет линкера и каждый раз когда нужно скомпилировать проект будь добр скомпилировать все библиотеки которые ты юзал, т.к. добавляя новый класс реализующий интерфейс, измененяется енам этого интерфейса и реализации всех функций которые с ним работают
@tgitw-tq6iu
10 күн бұрын
@@miffop Я говорил про раст. Очевидно, что в нормальном языке даже без глобально закрытой системы типов таких проблем практически нет. А проблема закрытия системы типов не в том, чтобы убрать линкер он итак в том же цпп не используется и не может использоваться. Проблема в том, что существует необходимость динамического расширения. Допустим со всякими плагинами и не только. В том числе и поэтому везде и всюду всё обмазано си с классами до сих пор.
@tgitw-tq6iu
10 күн бұрын
фантазии автора на 14:00 демонстрируют ту проблему о которой я писал ранее. Автор берёт раст и тот факт, что там "статический" полиморфизм является таким же динамическим и делает вывод "мы можем заменить". Нет, ты можешь заменить именно потому реализация примитивна. Именно потому что язык не имеет нормальной поддержки полиморфизма. В языках с мощным динамическим/статическим полиморфизмом одно нельзя свести к другому. В языке, где полиморфизм одно название семантически динамическое и немного с монорфизацией, немного с интанцированием сигнатур. Там да - разницы нет, повторяю. Но это свойство немощности языка и реализации, а не полиморфизма. Это не значит что статический/динамический полиморфизм ~одно и тоже.
@tgitw-tq6iu
10 күн бұрын
Рассуждения автора про классификацию полиморфизмов является глупостью полной с попыткой подбить реальность под свои "язык" и свои представления. В реальности существуют два типа полиморфизма - полный и табличный. И табличный действительно не зависит от реализации. Неважно есть там виртуальный вызов или нет - это не меняет поведение. Это та самая ничего не значащая деталь. Причём автор каким-то образом называет енам динамическим полиморфизм хотя он им не является. Это вообще не полиморфизм. В нём ты обязан написать код для каждого из типов. Но частично такое можно назвать таблицей просто написанной руками в каждом месте использования. Настоящий полиморфизм или всякие его ограниченные попытки его реализовать типа высокородный/hkt. Он статический. Именно потому что типы разрешают статически. Там ненужно никаких таблиц. Ненужно никаких ограничений на один интерфейс. На один тип. В какой-то мере он более общая вариация структурного, но структурный полиморфизм вообще не полиморфизм. Он про то каким образом происходит тайпчекинг. Есть самая тупая реализация - через "наследование" как это происходит в жаве/расте/практически везде. Эта реализация максимально примитивна и потому популярна. А так же максимально тормозная и ограниченный. Структурный полиморфизм это про структурный тайпчекинг, который проверяет то соответствует ли контекст использования используемому типу. Это куда сложнее. Требует более мощной системы типов и тайпчекинга. Немощные языки типа раста в это принципиально не могут. Такой полиморфизм часто встречается в динамических языках потому что тайпчекинг там динамический и реализация этого не особо сложнее "наследования". Но в рамках статического тайпчекинга это очень редкое явление существующие разве что в цпп в степени достаточно для использования.
@KaraMaslyatam
10 күн бұрын
Чукча не смотрел ролик? Автор не раз говорит про условность разделения полиморфизма и ничего не конкретизирует. Енам он относит к условному динамическому полиморфизму, потому что напоминает АВТОРУ динамический полиморфизм, потому что он может работать с коллекцией "разных типов". Автор показывает лишь, что необязательно добавлять косвенную адресацию с таблицей вызовов, а получить почти то же самое, но дешевле по производительности. Опять же не факт, что всегда такой подход будет производительней, однако автор это отметил.
@tgitw-tq6iu
10 күн бұрын
@@KaraMaslyatam Ничего автор не показывает. Всё это было мною описано в комментах. К тому же енам не относится к полиморфизму по определению автора. Потому что он позволяет работать с разными типами данных. Там можно условно по тегу вытащить тип, но не более. Хотя определение автор явно взял из головы чтобы подбить фантазии под реальность. Динамический полиморфизм всегда про открытые типы. Никакая косвенной адресации там нет, а таблица вызовов есть - твой свич. Единственная разница в том, что в одном случае это закрытый тип и крестовый компилятор может это оптимизировать, а в другом случае открытый. Это важно, а не нелепые фантазии фанатиков. "почти тоже самое" ты не получаешь потому что не получаешь открытых типов. И получаешь тысячи копипасты, дырявое подучие днище - всё это было описано мною, но ни ни что ты не смог ответить. Потому что болтать и повторять чушь из интернета это одно, а понимать что-то и ответь совершенное другое.
@tgitw-tq6iu
10 күн бұрын
@@KaraMaslyatam Кстати, как быстро "является" стало "напоминает". Причём без конкретики со стороны автора.
@tgitw-tq6iu
10 күн бұрын
на 10:00 автор наконец-то смог сообщить о проблеме, которая присуща енаму убогому. Особенно в том как он реализован в расте. И анам так же тормозит. И я уже подумал что автор чекнул своё невежество, но нет. Он начал рассказывать истории про "вы пишите код для себя". Я понимаю, конечно, что кроме лаб "для себя" на расте действительно ничего не пишут и написать в принципе не очень реально, но всё же. Если я пишу код для себя мне что ненужно его расширять/изменять? Мне ненужно добавлять новые фигуры? Или ты хочешь чтобы я руками в 1000 местах менял эти свичи? В этом проблема. В том, что этот свич нужно писать в каждом месте, где используется енам. Кстати, не помогут здесь и всякие сказки с сообщениями об ошибке, потому что почти все свичи который я видел в расте содержат _, а значит когда ты добавишь новый элемент у тебя просто даже сообщений об ошибках не будет. И в случае что-то в рантайме упадёт.
@user-kn9ot2gw6h
10 күн бұрын
Помню, тоже очень страдал от этого. Очень круто было бы иметь в расте что-то похожее на std::visit из c++. Проблема с миллионом свичей в миллионе мест всё же легко решается тем, чтобы спрятать их внутри методов самого же енама, но по-моему это довольно костыльно и вносит свои коррективы в то, как пишется код
@tgitw-tq6iu
10 күн бұрын
@@user-kn9ot2gw6h std::visit это 10 строчек кода и ничего не делает. Важен дизайн языка, система типов и полиморфизм. В расте ничего из этого нет. Ничего не решается - лапша с прятками свичей в методы не решает какой-либо проблемы. Ты как минимум один раз напишешь то, что писать ненужно. Ты будешь все эти места обновлять. Ты не сможешь ничего расширять. Это не "коррективы" это полностью дырявый врайтонли подход. Допустим тем, что убогий енум отравляет твой код и ты везде должен его использовать. Даже если ты будешь не все типы, либо вообще один - тип всегда стирается. Обернуть что-то в енум так же не представляется возможным без адского костылинга, который даже никогда нормально работать не будет. В результате всё что позволяет оборачивание спрятать за условным call call_a, call_b.
@dmitriyivanich1088
9 күн бұрын
нет чел, вместо свичей можно делать таблицы (индексируемые енамами) и функцию доступа к этой таблицы. у тебя есть MyEnum, MyEnumTable и функция DoSmthWithMyEnum( MyEnum e ) { return MyEnumTable[ e ]; } и все никаких свичей.
@tgitw-tq6iu
9 күн бұрын
@@dmitriyivanich1088 Какие-то фантазии. Таблица чего? Таблица зачем? Начни с приведения с примеров раз какие-то сложности даже с примитивным набросом.
@dmitriyivanich1088
9 күн бұрын
@@tgitw-tq6iu Чел это широко известная техника для системных языков программирования. Но вот тебе пример на с++, про рисования фигур. struct FigureType { enum Enum: size_t { FIGURE_TYPE__SQUARE , FIGURE_TYPE__TRIANGLE , FIGURE_TYPE__CIRCUL , FIGURE_TYPE__TOTAL }; }; struct Figure { public: using FigureDrawFn = std::function</*TODO: draw function signature*/>; using FigureDrawTable = std::array<FigureDrawFn, FigureType::FIGURE_TYPE__TOTAL>; public: /*TODO: draw function return type*/ draw() { return m_FigureDrawTable[ m_Type ]; } private: FigureType::Enum m_Type; private: static const FigureDrawTable m_FigureDrawTable; }; const Figure::FigureDrawTable Figure::m_FigureDrawTable = { // FIGURE_TYPE__SQUARE []( /*TODO: function parameters*/ ) -> /*TODO: function ret type*/ { /*TODO: function body*/ }, // FIGURE_TYPE__TRIANGLE []( /*TODO: function parameters*/ ) -> /*TODO: function ret type*/ { /*TODO: function body*/ }, // FIGURE_TYPE__CIRCUL []( /*TODO: function parameters*/ ) -> /*TODO: function ret type*/ { /*TODO: function body*/ }, };
@tgitw-tq6iu
10 күн бұрын
8:11 - очередное враньё про цпп и то, что "суть одна" "одинаковый набор методов". Нет. Здесь автор пытается навязать ограничения примитивной раст-реализации на остальные реализации. Остальные умеют наследование, множественное наследование, виртуальное наследование rtti с приведением по иерархии. В каких-нибудь жавах есть рефлексия. Реализация раст просто самый примитивный костыльный костыль из бородатых годов, которая каким-то образом приравнивается к другим с навязыванием им тех же свойств/ограничений.
@cordestandoff2358
10 күн бұрын
Выдал базу, шикарный ролик. Но почти каждый, кто изучил раст, знает хотя бы примерно об этой теме. Хотелось бы кстати ролик про crates, rust без cargo или еще что-нибудь подобное
@bitwiseuwu
10 күн бұрын
Rust без cargo интересная тема, но мне кажется она перестаёт быть интересной если знать о команде cargo build -verbose, который показывает все вызовы rustc. То есть карго просто упрощает взаимодействие с компилятором, ничего особо интересного там нет. А ролик про crates - ты имеешь ввиду про структуру проекта и зависимости или про репозиторий crates io?
@cordestandoff2358
10 күн бұрын
@@bitwiseuwu Структура проекта. Я просто увидел на стриме тсодинга от него вопрос: "кто здесь шарит в крейтах?" А по факту для меня это выглядит просто как use crate::..., но наверняка в этом какой то глубинный смысл :) Но спасибо за --verbose, довольно интересно. Было бы прикольно без карго условно собрать tokio, вроде хорошая задачка для rust development'а
@cordestandoff2358
10 күн бұрын
Можно еще кстати про биндинги рассказать, хотя это как бы есть в rustbook. Вообще не представляю, на какие темы ты будешь снимать видосы, когда есть rustbook :)
@bitwiseuwu
10 күн бұрын
@@cordestandoff2358 удивительно, но Rust book скорее помогает придумывать темы, потому что объяснения там не всегда самые лучшие. Она пытается быть достаточно технической, хотя иногда легче нарисовать и показать наглядно, чем описывать текстом.
@tgitw-tq6iu
10 күн бұрын
5:50 - полиморфизм с генериками в расте не имеет никакого отношения к статического полиморфизму. Это семантически тот же динамический полиморфизм, но с монорфизацией. А генерики там используются совершенно для иного. Далее пошла какая-то чушь про "максимальную скорость" ни к какой скорости отношения это не имеет. Оно там всё максимально тормозное. Самое смешное тут то, что автор говорит "нам неважно что draw", но что изменилось? Генерикам важно что draw? Нет, неважно. Ничего не меняется. Здесь проблема того как засунуть всё это в один вектор, а не в том что и как вызывает и что и кому важно. Поэтому нужно помазать боксингом.
@tgitw-tq6iu
10 күн бұрын
4:14 Нет, никакой раст ничего не знает об оптимизациях и функциях. Очередное враньё. Почему там прикрутили монорфизацию я сообщил ранее. Зачем монорфизация нужна в языках без боксинга? Ответ очень прост и не связан с той чушью, что автор вещает. Есть проще, то процессор не знает ничего про полиморфизм и прочие сказки. Весь код должен быть мономорфен. Если есть два разных типа - ты либо делаешь 2 разных функции, либо приводишь эти два типа к одному внутреннему типу(что и является боксингом).
@KaraMaslyatam
10 күн бұрын
Это ты вещаешь чушь. Начинаем с того, что автор не говорил, что именно раст знает что-то об оптимизациях и про процессор. Откуда ты вообще взял это? В ролике про это ни слова. Ты что-то сам выдумал и заявляешь, что это враньё. Конечно враньё, только с твоей стороны. Опять же, можно заявить, что LLVM является частью Rust и будешь уже прав. А ты просто докапываешься до терминологии и непонятно, что хочешь доказать. Боксинг, мономорфизация, люди, кони... Зачем делать 2 разных функции, если дженерики с этой самой мономорфизацией для этого и есть? Короче, бредятина.
@tgitw-tq6iu
10 күн бұрын
@@KaraMaslyatam Говорил. "примером является язык раст", "компилятор имеет возможность создать", "производительность". Я даже таймкод дал, но врать твоя природа. Каким образом ллвм является частью раста? Может крестовая модель памяти является частью раста? Может цпп является частью раста? Может крестовый рантайм является частью раста? Может сишный рантайм является частью раста? На каком основании? Далее без конкретики просто забрасывает меня своим невежеством. Монорфизация не имеет отношения к генерикам. Опять наврал. Монорфизация и есть, маня, делать две разных функции. То, что они делаются за тебя не означает что их делать ненужно. Я где-то писал что их руками нужно делать? Опять надул в портки?
@tgitw-tq6iu
10 күн бұрын
Истории про "компилятор может создать отдельную функцию" никак не связано с интефрейсами и генериками вообще. Это монорфизация, которая в расте появилась вопреки. Монорфизация часть полиморфизма в языке без боксинга. Поэтому когда к раста срочно переделывали чтобы крипрутить его к цпп-компилятору пришлось добавлять монорфизацию. Но семантического боксинга она не убрала. И этот интерфес и есть боксинг, который создан в языках с генериками/интерфейса/наследованием именно потому что там нет монорфизации.
@tgitw-tq6iu
10 күн бұрын
Удивительно как манипуляции и невежество порождают фичу из дыры. Интерфейсы, а не данные там существуют по той причине что реализовать их в 10раз проще, а не из-за твоих фантазий и придуманных задним числом историй. В примере с си(в котором почему-то оказалась ссылка) вообще враньё. Потому что никакие имена полей как и дополнительные поля ни на что не влияет. Там влияет только расположение данных в памяти. Наследование используется только по одной причине - его реализовать в 100 раз проще чем структурный полиморфизм(пример которого ты даже не показал. В си это не структурный полиморфизм).
@KaraMaslyatam
10 күн бұрын
Опять какой-то поток бреда. Но про расположение данных в памяти и насильное приведение типа действительно стоило упомянуть, так сейчас никто не делает естественно. Да и вообще это UB по дефолту для любого адекватного программиста.
@tgitw-tq6iu
10 күн бұрын
@@KaraMaslyatam Фанатики с пробитыми портками уже в уб записывают всё, что им удобно. Хотя почему уже - они всегда так делали.
@snatvb
10 күн бұрын
ты еще бы мог затронуть impl, ведь это аналог dyn в некоторых кейсах, когда ты хочешь использовать трейты, но тебе нет смысла делать это через жирный указатель
@bitwiseuwu
10 күн бұрын
impl Trait - это очень специфическая для Rust штука, для которой есть много вариантов, про него можно сделать отдельное видео, поэтому не хотелось растягивать это
@snatvb
10 күн бұрын
@@bitwiseuwu может стоит запилить? мне кажется многие не понимают как раз этих приколов) я сам на расте не пишу, просто нравится, и как я понимаю, он работает похожим образом на дженерик, который при компиляции делает варианты
@usercommon1
10 күн бұрын
Approved by true Rust patriot
@vartan_babayan_4388
10 күн бұрын
крутой ролик, спасибо!
@zoodogood
10 күн бұрын
Ого. Спасибо за старания. Очень интересно получилось
@white5493
10 күн бұрын
очень круто, спасибо. как раз в своем проекте использовал динамичиский тип, при этом у меня еще объект помещен в OnceCell, думаю попробовать переписать на enum.
Пікірлер