2. Время жизни, ADT. Программирование на Rust (весна 2019) 

спасибо, заметили, владение куда засунули?

Для **полей* мы действительно хотим сумму, и размер структуры без полей это ноль. Но тут речь идёт не о n полях, а об n вариантах enumа, и тут размер определяется не суммой а, примерно, максимумом. И именно с -oo арифметика работает так, как мы хотим. Пусть есь тип `enum Void { }` и тип `struct Pair { x: i32, void: Void }`. Кажется логичным, чтобы sizeof ы у этих двух типов были одинаковые -- для обоих типов множество допустимых значений пусто. Получаем, что мы хотим чтобы size_of::() == size_of::() + size_of::(), что как раз даёт -oo как разумный ответ.

@@alekseykladov1144 спасибо, теперь понятно.

На представления в памяти tuple vs record не влияет

Попробуй

ааа.. бл я сам понял 🤪 in the large... in the small

Это скорее костыль, а не продуманная фича языка)

​@@TheTmLevтаки не баг, а фича. Называется идиома immediately invoked lambda expression (IILE)

@@makaedg в плюсах чаще всего все идиомы - попытки обойти плохой дизайн языка) В Расте есть нормальная блочная инициализация, в плюсах приходится костылить IILE

@@TheTmLev ну хз, IILE нормальная конструкция. Имхо наоборот, блочная инициализация выглядит как костыль с целью сэкономить 10 секунд на написании свободной функции. Ещё и return неявный Поскольку в плюсовой лямбде нужно явно указать captures, то при рефакторинге она на изи выносится как функция. Как это организовано в случае с блочной инициализацией?

@@makaedg > костыль > сэкономить на написании свободной функции Предлагаю вернуться к этому диалогу попозже)

А в Scala и Kotlin есть Nothing. Про Scala не скажу, а в Kotlin конструкция while (цикл) и throw (бросить исключение) возвращают Nothing. И Nothing является подтипом любого другого типа.

потому что log 0 по любому основанию = -inf, а размер Result, поскольку это энум равен максимальному размеру, то есть max(sizeof(T), sizeof(Void)), что равно sizeof(T) если это не Void

@@alexeygerasimov5976 А логарифм-то тут причём? Размер не Result не равен максимальному размеру. Он равен макс размеру + размер дискриминанта (который может быть нулевым), но это не важно. Не лучший пример. Вот какой-нибудь (u32, Void) либо структура с теми же полями, не суть.

логарифм при том, что размер типа в битах есть логарифм по основанию 2 мощности множества всех возможных значений типа, например для bool нужен один бит, потому что bool представляет 2 значения и log_2(2)=1, если у типа одно значение (Unit, или () в расте), то log_2(1) = 0, это пример ZST, а для Void значений 0, поскольку тип ненаселен, log_2(0) = -inf, про дискриминант забыл, но с ним даже проще показать что размер резалта не будет -inf, т.к для дискриминанта хоть один бит да нужен `Вот какой-нибудь (u32, Void)`, такой тип это тоже Void, поскольку второй компонент кортежа ты создать не сможешь, а значит не сможешь оздать и весь кортеж, а значит это Void, и его размер -inf

​@@alexeygerasimov5976 size_of к битам никакого прямого отношения не имеет правда. Он возвращает размер типа в байтах. Другое дело, что для ненаселённых типов его значение не имеет какого-либо смысла. Тут уже какой-нибудь Option(usize) подошёл бы больше, но уже поздно менять сигнатуру size_of, поезд ушёл с 1.0.

@@flashmozzg, ну -inf именно из теории информации идет, а вы про практическую реализацию говорите, и про Option может быть логично, но -inf все равно в целых числах не закодируешь, и число байт это натуральное число, поэтому если где-то получается -inf, то берут 0, это как использовать unit для Result, который всегда Ok, поскольку настоящего void пока нет, да это и не особо мешает, хотя помогло бы компилятору понять что ошибки быть никогда не может в таком Result'e и сделать какие-то оптимизации

Vec - это владеющий тип, он может менять свой размер. А срез - это ссылка на последовательность элементов определенной длины, это всегда заимствующий тип и свою длину он менть не может (но может менять элементы в своем составе). Грубо говоря, срез - это просто указатель на последовательность элементов в памяти (в массиве или векторе) плюс длина.

@@alexanderxx2982 > "но может менять элементы в своем составе" Разве срез может менять свои элементы? У меня не получилось - компилятор ошибку выдает. Приведите свой код, который такое умеет делать.

Зачем так сложно? `let` регулирует значение именно по скоупу. Т. е. переменная не будет видна извне как и в Rust, а вот старик `var` - да, только функции и всякое. P. S. Чем плох JS? :) Люблю его и не люблю когда его обвиняют в том, что он плох для микроконтроллера, смекаешь мысль?

В C++ точно так же

Не знаю чем всрато...

loop и есть выражение. while в zig выражение если у него есть else, у раста у while вообще не может быть else

@@nanoqsh и из loop можно возвращать результат?

checkout first lecture

Через 10 лет rust умрёт и будет никому не нужен. Это такая же мода, как была 7-10 лет назад с функциональными языками программирования, microsoft даже на хайпе F# выкатили, который в итоге на хрен никому не сдался кроме как поиграться. В результате удачные наработки добавили в C# (стараясь не портить совместимость, конечно), а на F# забили. А тогда все говорили что мол всё, теперь вместо C будет компилируемый lisp, вместо java - ML и Scala. Ну хотя Scala ещё ладно. Где теперь все эти языки и где успешные проекты на них? Продакшен, требующий производительности как писали на C (чистом) так и будут. Rust тупо неудобно использовать, т.к. гораздо проще создав грамотную архитектуру контролировать память на C, чем рвать задницу разгребая бесконечный свод правил, время жизни, разные структуры данных и прочую хрень на rust. Этим кстати и C++ страдает отчасти, но разница в том, что в C++ или скажем C# можно отказаться от того что вам не нравится, а в Rust его "модные" структуры данных поставлены во главу угла ТУПО ДЛЯ ТОГО, чтобы память не текла. Вы бл*дь серьёзно? Я уж молчу о том, что rust сейчас использует всё наследие C - и это огромное лицемерие. Нет проектов чисто на Rust, всегда Rust - это обёртка для сишной библиотеки, а крейты на rust - бесполезное дерьмо.

@@MariaEsenina Молодой язык, относительно, конечно. Всё впереди; мне он нравится гораздо больше C/C++, а его особенности ради контроля памяти не сильно-то и обременяют, зато профит какой. Плюс (ульта для меня) - Zero Cost Abstractions на функциональщину (не всегда, но мечтать не вредно). C/C++ обязаны тянуть легаси, выворачиваются чтобы вводить новые фичи без потери обратной совместимости, что приводит к тому, что кардинальное развитие/улучшение для них недоступно. А мир-то меняется и быстро, особенно IT.

@@JohnDoe-lw7yb сразу видно человека, который повёлся на пиар)). Во-первых работа с памятью в Rust как раз таки обременяет (именно на то, что в отличие от C у вас вообще нет выбора как с ней работать!). В C можно создать собственный аллокатор и сборщик мусора, который будет в разы удобнее для большинства задач. Zero cost abstractions - здесь вообще рука тянется к пистолету, это вообще бредятина по сути, т.к. в C/C++ они тоже zero cost, ОСОБЕННО в C, где struct - с точки зрения памяти вообще не существует, указатель на структуру == указателю на первый элемент этой структуры, эту фишку иногда применяют для параметрического полиморфизма (а некоторые стреляют в ногу не зная как этим пользоваться или случайно, т.е. внезапно в C можно даже применять функциональщину! (кстати в C++ СИшные фишки компилятор запрещает)). Rust это вроде как умный язык с ЗАЩИТОЙ ОТ ДЕБИЛОВ! И как самостоятельный инструмент он не нужен, для системного программирования так и вовсе (так или иначе там будет использоваться unsafe, а если это так, то нафига это надо? когда есть C, проверенный десятилетиями опыта). Кстати в компилируемом LISP почти zero cost abstractions, макросы и лямбды самые мощные среди вообще ЛЮБЫХ ЯП, при этом в отличие от Rust не навязывает никакой стиль, взлетел? Нет! Причём ни один из LISPов, включая новомодный Clojure, хотя все модные "функциональные" фишки заимствованы из него. LISP кстати гораздо лучше подошёл бы именно для Web программирования, но выигрывает всегда либо эффективность (как в случае с C), либо тупость, как в случае с (JavaScript). Rust это умный язык, который хочет заставить людей прыгать под свою дудку и в этом он уже проиграл C. Линус как-то очень чётко ответил почему C вне конкуренции - C очень близок к среднему "академическому" машинному языку и хорошая зная C разработчик знает как работает железо. Rust же наплодил кучу структур данных, которые уже давно существуют в любом языке, при этом чтобы написать эффективный проект желательно использовать только Rust. Сегодня же любой проект на Rust - это вызовы Сишных библиотек. Вам невдомёк, что C используют далеко не только из-за Легаси, а именнно из-за эффективности, т.к. C не заставляет думать в рамках "классических" STL-вских структурах данных. Rust же по сути язык с сумасшедшей работой с памятью и прикрученным сбоку STL-подобным монстром (от которого кстати даже некоторые плюсовики отказываются!). Что РЕАЛЬНО в Rust хорошо, по крайней мере в плане идеи - это параллелизм и многопоточность, в этом его единственная классная фишка, о который кстати Вы даже не упомянули. Тем не менее это не прокатит, у Erlang тоже классная многопоточность и асинхронность, язык мёртв, его фичи скоммуниздили мейстримные языки. С точки зрения практики проще на решётках писать (C#), если хочется из коробки мощные структуры данных. Знаете, мне на самом деле в какой-то мере хочется чтобы Rust взлетел, но правда такая, что это очередное веяние моды, которое как это всегда бывает ни к чему не приведёт. Я помню статьи про "убийц Java" вроде Groovy и упомянутом Clojure, сейчас люди даже не знают что такие языки КОГДА-ТО БЫЛИ!

@@MariaEsenina Повёлся или нет, но с C++ мы на ножах, а с Rust вполне так работаем. Скорость, удобство, удовлетворение, что ещё нужно? :) Проблем много, но их решают... в целом. А вечность сидеть на одном (ну двух) *монументальных* языках при условии что всё развивается и тот же аллокатор можно где-то автоматом прятать, не отвлекая программиста на его *эффективную* реализацию (хм, Rust?) - глупо. Я ещё не адепт Rust, но пока меня всё устраивает. Я уважаю C/C++, но высокоуровневый ассемблер - это перебор. Все фломастеры разные, верно? P. S. JS не туп, его надо уметь готовить; плата за популярность такая.

Как и в си и плюсах. Только это не является выражением, в отличие от раста и требует заранее объявить переменную, вместо того, чтобы вернуть её из блока. В расте же блоки можно использовать как выражение и это часто бывает удобно, можно писать что-то вроде: { let x = make_x(); x * x } + 2

Интересно, я смотрю на скорости 2.0 и всё окей. Скорее всего или у вас дешевое устройство воспроизведения или же этот материал слишком сложен для вас(советую посмотреть на более высокоуровневые языкы программирования, можно начать даже с HTML, там будет намного легче)

Интересно, я смотрю на скорости 2.0 и всё окей. Скорее всего или у вас дешевое устройство воспроизведения или же этот материал слишком сложен для вас(советую посмотреть на более высокоуровневые языкы программирования, можно начать даже с HTML, там будет намного легче)

@@chasing_the_horizon программирую на с++

Это норма среди разработчиков, потому что вся документация на английском, да и когда долго общаешься на английском то вообще забываешь как эти выражения на русский переводятся. Приходится напрягаться и вспоминать. Проще англицизмы использовать. Те, кто в теме - все все понятно. 🤷‍♂️

Многим удобнее слушать на родном языке, чем учить для этого второй

@@moshamiracle ну продавайте огурцы на рынке если влом учить английский, который дефакто обязателен любому разрабочику)

@@luden6794 благодарю, пожалуй останусь дальше айтишницей)

@@moshamiracle да я просто не понимаю почему такое отторжение от языка который даёт настолько много возможностей и который так просто выучить