Очень интересно. Живой рассказ с иллюстрациями и примерами хорошо дополняет текст книги, и некоторые концепции после лекции становятся более понятными. Жаль, что не слышно вопросов. Лектору нужно было бы, хотя бы, повторять вопросы перед ответами на них.
Для **полей* мы действительно хотим сумму, и размер структуры без полей это ноль. Но тут речь идёт не о n полях, а об n вариантах enumа, и тут размер определяется не суммой а, примерно, максимумом. И именно с -oo арифметика работает так, как мы хотим. Пусть есь тип `enum Void { }` и тип `struct Pair { x: i32, void: Void }`. Кажется логичным, чтобы sizeof ы у этих двух типов были одинаковые -- для обоих типов множество допустимых значений пусто. Получаем, что мы хотим чтобы size_of::() == size_of::() + size_of::(), что как раз даёт -oo как разумный ответ.
51:10 На С++ можно что-то похожее сделать с лямбдами auto omlet = [&] { auto eggs = get_eggs(refrigerator, 3); auto bacon = open_bacon(refrigerator); return fry(eggs, bacon); }();
@@makaedg в плюсах чаще всего все идиомы - попытки обойти плохой дизайн языка) В Расте есть нормальная блочная инициализация, в плюсах приходится костылить IILE
@@TheTmLev ну хз, IILE нормальная конструкция. Имхо наоборот, блочная инициализация выглядит как костыль с целью сэкономить 10 секунд на написании свободной функции. Ещё и return неявный Поскольку в плюсовой лямбде нужно явно указать captures, то при рефакторинге она на изи выносится как функция. Как это организовано в случае с блочной инициализацией?
50:33 В JS (Господи, прости) есть прием, которым можно достичь подобного эффекта - это Immediately Invoked Function Expression (IIFE) let omelette = function (){ let eggs = get_eggs (...); let bacon = get_bacon (...); return fry (eggs, bacon) }(); Всрато, да)
Зачем так сложно? `let` регулирует значение именно по скоупу. Т. е. переменная не будет видна извне как и в Rust, а вот старик `var` - да, только функции и всякое. P. S. Чем плох JS? :) Люблю его и не люблю когда его обвиняют в том, что он плох для микроконтроллера, смекаешь мысль?
как-то не идеоматично. Раз уж if else является выражением, то почему while и loop нельзя сделать полноценным выражением. Если не ошибаюсь, то в Zig это реализовано. Возвращать значение можно через break.
@@feelamee да, из loop можно вернуть результат с помощью break, на пример: fn main() { let mut i = 0; let num = loop { if i == 10 { break i; } i += 1; }; assert_eq!(num, 10); }
А в Scala и Kotlin есть Nothing. Про Scala не скажу, а в Kotlin конструкция while (цикл) и throw (бросить исключение) возвращают Nothing. И Nothing является подтипом любого другого типа.
Vec - это владеющий тип, он может менять свой размер. А срез - это ссылка на последовательность элементов определенной длины, это всегда заимствующий тип и свою длину он менть не может (но может менять элементы в своем составе). Грубо говоря, срез - это просто указатель на последовательность элементов в памяти (в массиве или векторе) плюс длина.
@@alexanderxx2982 > "но может менять элементы в своем составе" Разве срез может менять свои элементы? У меня не получилось - компилятор ошибку выдает. Приведите свой код, который такое умеет делать.
50:33 в C# есть подобная штука с блоками, называемая "контестом" static void Main(string[] args) { int z; { int a = 10; int b = 20; z = a + b; } z = z + a; //The name 'a' does not exist in the current context }
Как и в си и плюсах. Только это не является выражением, в отличие от раста и требует заранее объявить переменную, вместо того, чтобы вернуть её из блока. В расте же блоки можно использовать как выражение и это часто бывает удобно, можно писать что-то вроде: { let x = make_x(); x * x } + 2
Интересно почему size_of() должен быть равен -inf, а не 0? Сумму пустого множества обычно определяют как нейтральный элемент (0 в данном случае), так что всё сходится. Иначе получится, что size_of какой-нибудь структуры с Void полем (тем же Result) станет внезапно -inf.
потому что 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 и сделать какие-то оптимизации
Через 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 не туп, его надо уметь готовить; плата за популярность такая.
Интересно, я смотрю на скорости 2.0 и всё окей. Скорее всего или у вас дешевое устройство воспроизведения или же этот материал слишком сложен для вас(советую посмотреть на более высокоуровневые языкы программирования, можно начать даже с HTML, там будет намного легче)
Интересно, я смотрю на скорости 2.0 и всё окей. Скорее всего или у вас дешевое устройство воспроизведения или же этот материал слишком сложен для вас(советую посмотреть на более высокоуровневые языкы программирования, можно начать даже с HTML, там будет намного легче)
Это норма среди разработчиков, потому что вся документация на английском, да и когда долго общаешься на английском то вообще забываешь как эти выражения на русский переводятся. Приходится напрягаться и вспоминать. Проще англицизмы использовать. Те, кто в теме - все все понятно. 🤷♂️
00:00:37 - Ссылки
00:04:40 - Move
00:06:38 - Copy
00:11:20 - Жизнь без ссылок
00:13:37 - Время жизни ссылки
00:14:57 - Ссылки на значения
00:16:57 - Именовынные время жизни
00:19:36 - Ссылки на подобьекты
00:21:38 - Что такое 'a?
00:24:16 - Заморозка
00:28:16 - mut
00:30:02 - Shared ^ Mutable
00:33:50 - Ссылки в С++ и Rust
00:39:44 - Итого
00:47:04 - Выражения
00:48:17 - Блоки
00:49:38 - Инициализация блоком
00:51:25 - if
00:54:08 - while
00:54:45 - break и continue
00:55:07 - loop
00:58:40 - Гарантированная инициализация
01:00:26 - !
01:01:40 - panic!()
01:03:08 - break со значением
01:03:26 - for
01:04:01 - ranges
01:04:55 - Ещё раз о ;
01:06:00 - Два слова о функциях
01:08:32 - Алгебраические типы данных
01:08:42 - Структуры
01:09:48 - Методы
01:12:50 - Ассоциированные функции
01:13:53 - Deref
01:14:49 - Структуры-кортежи
01:16:44 - Паттерн newtype
01:19:10 - Zero Sized Types (ZST)
01:20:30 - Type Tags
01:21:14 - Виды структур
01:21:28 - Dynamically Sized Types (DST)
01:23:35 - Slices
01:26:56 - Enums
01:32:12 - Полезные enumы
01:34:39 - Newtype Variant
01:35:25 - Void
01:37:06 - Result
01:38:40 - Представление в памяти
спасибо, заметили, владение куда засунули?
Очень интересно.
Живой рассказ с иллюстрациями и примерами хорошо дополняет текст книги, и некоторые концепции после лекции становятся более понятными.
Жаль, что не слышно вопросов.
Лектору нужно было бы, хотя бы, повторять вопросы перед ответами на них.
Алексей не реально грамотный преподаватель, вот это мозг. Почтение.
todo!() на состояние 25 октября 2020 уже есть =) Ура!! =)
Отличная лекция!!! На английском я такой еще не находил.
Докладчик шарит , супер доклад , спасибо
Очень круто. Я Front-end Developer. Решил для общего развития подучить Rust. Лекции очень кстати!
Спасибо за прекрасную лекцию)
Лектор просто боженька
Не все свитчатся в раст с плюсов.
За аналогии с плюсами - спасибо, но хотелось бы и с другими языками
Благодарю, теперь стала понятна логика владения и вж
спасибо за познавательную лекцию!
as far as I know, newtype in Haskell is also zero cost abstraction
Супер
Почему сумма size_of'oв нуля полей должна быть -inf? вроде логично предположить что 0.
Для **полей* мы действительно хотим сумму, и размер структуры без полей это ноль. Но тут речь идёт не о n полях, а об n вариантах enumа, и тут размер определяется не суммой а, примерно, максимумом. И именно с -oo арифметика работает так, как мы хотим.
Пусть есь тип `enum Void { }` и тип `struct Pair { x: i32, void: Void }`. Кажется логичным, чтобы sizeof ы у этих двух типов были одинаковые -- для обоих типов множество допустимых значений пусто. Получаем, что мы хотим чтобы size_of::() == size_of::() + size_of::(), что как раз даёт -oo как разумный ответ.
@@alekseykladov1144 спасибо, теперь понятно.
51:10
На С++ можно что-то похожее сделать с лямбдами
auto omlet = [&] {
auto eggs = get_eggs(refrigerator, 3);
auto bacon = open_bacon(refrigerator);
return fry(eggs, bacon);
}();
Это скорее костыль, а не продуманная фича языка)
@@TheTmLevтаки не баг, а фича. Называется идиома immediately invoked lambda expression (IILE)
@@makaedg в плюсах чаще всего все идиомы - попытки обойти плохой дизайн языка)
В Расте есть нормальная блочная инициализация, в плюсах приходится костылить IILE
@@TheTmLev ну хз, IILE нормальная конструкция. Имхо наоборот, блочная инициализация выглядит как костыль с целью сэкономить 10 секунд на написании свободной функции. Ещё и return неявный
Поскольку в плюсовой лямбде нужно явно указать captures, то при рефакторинге она на изи выносится как функция. Как это организовано в случае с блочной инициализацией?
@@makaedg
> костыль
> сэкономить на написании свободной функции
Предлагаю вернуться к этому диалогу попозже)
50:33
В JS (Господи, прости) есть прием, которым можно достичь подобного эффекта - это Immediately Invoked Function Expression (IIFE)
let omelette = function (){
let eggs = get_eggs (...);
let bacon = get_bacon (...);
return fry (eggs, bacon)
}();
Всрато, да)
Зачем так сложно?
`let` регулирует значение именно по скоупу.
Т. е. переменная не будет видна извне как и в Rust, а вот старик `var` - да, только функции и всякое.
P. S. Чем плох JS? :)
Люблю его и не люблю когда его обвиняют в том, что он плох для микроконтроллера, смекаешь мысль?
В C++ точно так же
Не знаю чем всрато...
45:18 на что влияет?
ааа.. бл я сам понял
🤪
in the large... in the small
1:36:16 - то есть эту функцию просто нельзя вызвать?
Попробуй
как-то не идеоматично. Раз уж if else является выражением, то почему while и loop нельзя сделать полноценным выражением. Если не ошибаюсь, то в Zig это реализовано. Возвращать значение можно через break.
loop и есть выражение. while в zig выражение если у него есть else, у раста у while вообще не может быть else
@@nanoqsh и из loop можно возвращать результат?
@@feelamee да, из loop можно вернуть результат с помощью break, на пример:
fn main() {
let mut i = 0;
let num = loop {
if i == 10 {
break i;
}
i += 1;
};
assert_eq!(num, 10);
}
Ненаселенный тип в Х-ле - это Void.
А в Scala и Kotlin есть Nothing. Про Scala не скажу, а в Kotlin конструкция while (цикл) и throw (бросить исключение) возвращают Nothing. И Nothing является подтипом любого другого типа.
Возможно глупый вопрос(про new type variant): а если варианты енума это тупл-стракты, то тоже будет паддинг лишний?
На представления в памяти tuple vs record не влияет
01:45:00 - страных -> странных
И чем принципиально отличаются векторы и слайсы?
Vec - это владеющий тип, он может менять свой размер. А срез - это ссылка на последовательность элементов определенной длины, это всегда заимствующий тип и свою длину он менть не может (но может менять элементы в своем составе). Грубо говоря, срез - это просто указатель на последовательность элементов в памяти (в массиве или векторе) плюс длина.
@@alexanderxx2982
> "но может менять элементы в своем составе"
Разве срез может менять свои элементы?
У меня не получилось - компилятор ошибку выдает. Приведите свой код, который такое умеет делать.
50:33
в C# есть подобная штука с блоками, называемая "контестом"
static void Main(string[] args)
{
int z;
{
int a = 10;
int b = 20;
z = a + b;
}
z = z + a; //The name 'a' does not exist in the current context
}
Как и в си и плюсах. Только это не является выражением, в отличие от раста и требует заранее объявить переменную, вместо того, чтобы вернуть её из блока.
В расте же блоки можно использовать как выражение и это часто бывает удобно, можно писать что-то вроде: { let x = make_x(); x * x } + 2
Интересно почему size_of() должен быть равен -inf, а не 0? Сумму пустого множества обычно определяют как нейтральный элемент (0 в данном случае), так что всё сходится. Иначе получится, что size_of какой-нибудь структуры с Void полем (тем же Result) станет внезапно -inf.
потому что 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 и сделать какие-то оптимизации
Готов ли Rust для промышленного програмирования? Не просто поделку написать и забросить. А поддерживать проект на протяжении 5 - 10 лет?
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 не туп, его надо уметь готовить; плата за популярность такая.
Лектор больше путает, чем объясняет
Че так сложно?
Если уж использовать англицизмы то "тАпл", а не "тУпл" 🤷♂️
Какая же хреновая дикция) Проглатывание слов, скороговорки в себя, на 0.75 и то сложно парсить) Очень жаль, интересно и мучительно больно.
Интересно, я смотрю на скорости 2.0 и всё окей. Скорее всего или у вас дешевое устройство воспроизведения или же этот материал слишком сложен для вас(советую посмотреть на более высокоуровневые языкы программирования, можно начать даже с HTML, там будет намного легче)
Вы же не берёте на работу плохого программиста, почему вы взяли вести лекции человека который еле еле говорит, ничё не понятно, какие то звуки просто
Интересно, я смотрю на скорости 2.0 и всё окей. Скорее всего или у вас дешевое устройство воспроизведения или же этот материал слишком сложен для вас(советую посмотреть на более высокоуровневые языкы программирования, можно начать даже с HTML, там будет намного легче)
@@chasing_the_horizon программирую на с++
Ему нужно на английском вести урок, дикая мешинина английского и русского языка. Каша порой.
Это норма среди разработчиков, потому что вся документация на английском, да и когда долго общаешься на английском то вообще забываешь как эти выражения на русский переводятся. Приходится напрягаться и вспоминать. Проще англицизмы использовать. Те, кто в теме - все все понятно. 🤷♂️
Многим удобнее слушать на родном языке, чем учить для этого второй
@@moshamiracle ну продавайте огурцы на рынке если влом учить английский, который дефакто обязателен любому разрабочику)
@@luden6794 благодарю, пожалуй останусь дальше айтишницей)
@@moshamiracle да я просто не понимаю почему такое отторжение от языка который даёт настолько много возможностей и который так просто выучить
czcams.com/video/WV-m7xRlXMs/video.html в C++23 завезли deducing this