Действительно господа, раньше я страдал от отсутствия оператора пайп "|". Без этого оператора я тупо не мог понять, как изменить ети переменные странные, а теперь как пойдет работа, как закрутиться все! Ух! Уже бегу изменять переменные, которые ждут своих изменений.
На самом деле это очень полезный оператор. Он позволяет 1. Писать более компактный код 2. Группировать изменения связанные с одной переменной вместе, что способствует читаемости кода. 3. Уменьшить в коде число переменных и констант что способствует уменьшению числа возможных ошибок связанных с этим. Это например тот момент из за которого некоторые люди переходят на функциональное программирование.
3:06 пайплайн-операторы не применяются к переменной по очереди; они вычисляют выражение, которое по итогу один раз записывается в переменную "num"; полезное нововведение
топ левел await - єто превращение вашего топ левел кода в генератор со всеми вытекающими: от самой большого потреблерия ресурсов по сравнению с другими возможностями js, до отсутствия єффективных способов оптимизации такого кода или крайняя сложность оптимизации таких генераторов. что абсолютно справедливо и для обычной async функции
Какие же бесполезные фичи только не придумают только чтобы не вводить паттерн матчинг. Просто сделайте нормальный паттерн матчинг чтобы не городить простыню из 10 if операторов господи прошу. Скоро будет 10 лет как висит RFC в репозитории TC39. Люди как только не изворачиваются чтобы контрлировать обработку ошибок. Возвращают строки, енамы или булеаны из функций. Пишут простыню из try/catch. Просто сделайте паттерн матчинг хотя на уровне оператора switch. Сделайте чтобы switch умел возвращать выражение как любом другом нормальной языке, а не вот эта клоунада со стейтментом. Сделайте чтобы if тоже был выражением. Господи боже. Нам ничего больше не надо для счастья. Нафига нам эти пайплайны или тьюплы?
Это вообще почти Erlang, на моих глазах язык перестает быть скриптиком для написания игр fluppy bird, вообще уже что-то академическое заезжает, круто, да.
@@funcelot осталось добавить статическую типизацию прямо на чистый JavaScript как многие это ждут. Я даже не знаю что случится с TypeScript тогда. И вообще примут ли это разработчики?
А какие методы groupBy для массивов ты считаешь самыми полезными?) я тоже недавно решил сменить сферу и выбрал курсы Skypro для этого)) долго сомневался но не пожалел))
@@TalkerTube надо в сторону оптимизаций копать, не интересовался глубоко, чё-то связано с ссылкой this, c захватом контекста компилятору сложнее обработать forEach
@@barbiturat1 будет адская смесь лучших практик из javascript, java и python. Основные конструкции типа массивов, циклов, аспекты и аннотации если джавист или промисов если на джаваскрипте пишешь должен знать наизусть + основной фреймворк языка. Плюс обызательно лайфкод на алгоритмы это на джун+/миддл у меня такое постоянно, я постоянно прохожу собесы и постоянно заваливаю хотя отвечаю на 80% всего что спрашивают. Лучшие практики никуда не уйдут, будет больше синтаксического сахара кому как бы не хотелось без него ну и да умение пользоваться нейронкой. Ещё думаю CI/CD сейчас + тестирование сейчас почти обязательно спрашивают на собесах. Ну на практике это отдельный человек, хотя не факт скажут вот нейронка за тебя всё пишет давай ещё и кубики поддерживай))
@@barbiturat1и как же ты будешь писать промпт нейросетке не зная языка на котором ей нужно что то написать? Это будет что то типа "Дядь, сделай красиво". Нейросетки ещё долго будут только помощниками. Но знать как с ними работать маст хэв.
node 22 версии все это есть, и в проекте можно использовать, но 22 нода сейчас не lts, вряд ли нормальный человек пустит аппликейшн с 22 нодой на продакшн
Костыли с решеткой это супер! На что только не идут люди, чтобы не делать нормальные свойства с геттерами и сеттерами и поля с модификаторами доступа! ))
суть tuple и records не только в том, что они иммутабельны, но и в свойствах, которые можно легко заиметь благодаря иммутабельности - сравнение по value (а не по ссылке) за константное время, не перебирая всю структуру, и, следовательно, становится возможным следующее: const map = new Map([ [#{ x: 0, y: 0 }, 'some value'] ]) map.get(#{ x: 0, y: 0 }) // 'some value'
Кложура все еще остается лиспом с развитой системой макросов, иммутабельностью переменных и ахуевшим количеством скобочек. Она всегда будет иметь преимущества перед жсом, впрочем как и недостатки
А как сделать такие подсказки, как у него? Я так понимаю это какой-то AI плагин? Но как он предугадывает? Или просто это уже было один раз написано перед записью видоса, а потом AI просто запомнил и предлагает?
о! Иммутабельные данные и пайплайны делают из JS почти Clojure! Очень интересный поворот. Я на clojure пишу лет 8 уже, может смогу опять писать на JS без рвотных позывов.
JS меняется, развивается - это круто. Скоро и типы строгие возможно подгонят, и нужны в TS больше не будет. А фишки норм, мне понравились. Ждём дженерики и модификаторы:)
immutable data structures. it is been 40 years to pass to just add this feature to ECMAScript 2024? what a nonsence. really. whole langueages were created including Erlang, Go, Rust just to have this feature as the first-class language objects, including well-known React library. Immutability of data and a way to mutate throught cloning and not modifyhing objects pass throught whole architecture patterns like distributed systems, in-memory online transaction processing, clusters and database processing, serverless, stateless systems. All of this made available just to the simple fact that we do not track modifications of exact objects in memory. We just doing f*n copies which takes off responsibility of sending events to subscribed objectst about changes in source object. that a heck a really, really old idea. I like that they finally implemented it not using whole micro-frameworks, but on a language level #. F*uck, this is best morning i've ever had since 1997 in js scripting. Thank you, you are real man! Great news, and keep going!
@@TheBoris83почему не глубокое? Если теперь все объекты под капотом будут иммутабельными, то их полное клонирование должно быть практически таким же быстрым как поверхностныое. Так реализовано например в языке Clojure.
а зачем использовать промис, если есть парадигма асинхронного программирования async-await ... я хочу сказать, что в этом смысле промис - рудимент ... или нет? )))
