Это не WiFi-модуль, это Orange Pi Zero, китайский одноплатник класса RPI ZeroW - чемпион по дешивизне среди одноплатников (< $10 в розницу с доставкой из Поднебесной). Вообще прикольный бизнес - взять одноплатник за 8 баксов, добавить корпус и DAC (еще баксов на 20 в сумме), написать прошивочку и продавать это за 150-200. Не-не не подумайте - я рад за ребят что они нашли свою нишу и решение придумали простое и экономически выгодное, раз люди покупают - то оно им нужно, но если конкретно вы хотите поковыряться в потрохах линукса на одноплатнике - то все это можно собрать чуть не на порядок дешевле.
Ну я все ж склонен верить людям, поскольку — это они этот язык налабали, там была куча разных очень сложных фич, так что в их квалификации сомневаться не приходится — с огромной долей вероятности и паттерн матчинг они наверняка осилили. А раз осилили — то чтобы не включить его в релиз нужны были веские причины. «Мало кому нужно» — причина весьма веская.
> от suspendable быстрее он не выполнится, и точно также будет ждать, пока завершится асинхронный вызов прежде, чем перейти к другому шагу.
Конечно быстрее не выполнится, но зато — мы явно видим где наш код может затупить надолго. И это хорошо и правильно, ПМСМ конечно же. Да, я помню что в самом начале использования корутин саспенды расползались по коду как тараканы на свету — но это быстро проходит, чутка опыта — и с этим можно жить.
> Вообще-то нет — это совершенно лишнее знание (да простит меня Роман Елизаров), требуемое конкретной реализацией асинхронности.
Как минимум — оно дает понимание что вот в этом конкретном месте программы, где мы вызываем suspendable функцию — программа может воткнуть и вернуться к исполнению через секунды и минуты. Это легче читается чем код в котором функции которые будут работать милисекунды и код который может вызвать запрос на гигабайт через пол-планеты — выглядят одинаково (как в каком-нить олдовом RPC).
> Навскидку, вам под suspendable придется переписать весь стек до самого низкого уровная I/O и JDBC
Да, если у меня в коде есть вызов функции которая начнет синхронно читать файл в гигабайт через пол-планеты — то у меня все воткнёт. Ну так мы в самом начале пути, библиотечные вызовы внутри которых могут быть такие вот радости — мы можем вынести в отдельные потоки и играться с ними там, благо делается это на тех же flows в пол-пинка. А со временем все больше и больше API будут становиться полностью асинхронными (потому как тренд это нынче, не пишут сейчас чисто блокирующих API), и радостей будет только больше.
Я вот не помню кто — Бреслау или Елизаров (скорее, первый) говорили что делали в Котлине полноценный паттерн матчинг — но релизить не стали по одной простой причине — кода там очень много а он оказался очень мало кому нужен. Говорят, если вы не пишете компилятор — то и паттерн матчинг вам ни к чему. Но как бы — радует что работа эта проведена, и если вдруг окажется что люди жить не могут без паттерн матчинга — то он довольно быстро в Котлине появится.
Вот кстати конкретно вывод типов ЛИЧНО МНЕ показался фичером сильно переоцененным. Ну т.е. да, оно наверное удобно не повторяться — но когда ты работаешь в IDE где она сама следит и подсказывает в процессе написания кода у кого какой тип — оно не шибко-то важно. И меняешь тип обычно тоже через рефакторинги IDE — тут тоже большой радости от меньшего количества изменений тоже нет. Зато страдает читаемость — когда у тебя
val x = something
val y = something.prop1
val z = something.fun2()
то для того чтобы понять типы переменных — надо возить мышкой. Так что частенько прописываешь тип даже если он не особо тут нужен — чтобы было за что глазу зацепиться.
А вот корутины это да, мне скоро Джетбрейнс стипендию назначит за то что я их нахваливаю, так что на Джаву теперь ни-ни, я за год ни одного листенера не написал и больше не собираюсь ;)
А что мешает вводить Котлин? Его радость в том что не надо переписывать все сразу, можно начать с мелких кусочков — к примеру, с тестов, с вспомогательных утилит и т.п. Котлин такая штука — как коллекционирование наркотиков в старом фильме с Джонни Деппом — единожды начав — очень сложно остановиться ;)
Вы вообще не о том спорите, и те кто ругает Котлин и те кто хвалит. Да, у Котлина приятный синтаксис и куча современных языковых фич — но это все красивые завитушки на чеке в миллион долларов. Господа, в Котлине есть корутины, и есть прямо сейчас, даже для древней джавы 1.6. И это его главный на данный момент фичер, все остальное — bells and whistles. Вам больше не нужно писать стейтмашины (чепчики в воздух!). Вам больше не нужно писать лесенки из. thenApply к CompletableFuture. А самое главное — вам больше не нужно это читать ломая глаза. Вам больше не нужны listener-ы к которым надо подписываться и потом не забывать отписаться. Ребят, это новая парадигма которая будет с нами следующее десятилетие (как минимум) — а вы тут спорите о том какой синтаксис для проверки типа переменной более правильный.
> Корутины? Очень интрузивное и тяжелое изменение, которое заставляет код выполняться совсем не так, как написано, разрезая сверху до самого основания ваш код на suspendable и не-suspendable.
Эм… Так это ж фича а не баг. Действительно надо понимать где код suspendable а где нет. И да, изменение тяжелое — но этот геморрой стоит свеч, особенно когда доходишь до flows и начинаешь их понимать. Нам не нужны стейтмашины. Нам не нужны листенеры. Мы можем асинхронно запускать кучу зависимых друг от друга задач в параллель не переживая ни о том что это сложно будет останавливать случись чего, ни о том что мы переусложняем логику поведения настолько что это невозможно будет потом сопровождать. Это другая парадигма, но её изучение окупается сторицей — единожды это раскурив ты получаешь левел-ап, и твой код никогда не будет прежним.
Одно дело — наличие асинхронного апи, другое — поддержка этого апи в языках. Если для асинхронного доступа к диску для чтения килобайта данных надо будет писать пол-экрана текста — то этим никто, ессесно, пользоваться не будет. А если асинхронный доступ будет выглядеть один в один как синхронный — так пуркуа бы не па.
С тем что современные программы так работают — процессор шустрый а данные лежат далеко, и часто — в разных местах. Т.е. нам нужно полезть, к примеру, одновременно по нескольким урлам, достать разные данные, да так чтобы данные полученные из одних могли отменить другие, или пользователь мог это отменить целиком или частично. Код на CompletableFuture для таких целей — это боль. Отдельные потоки на каждый запрос — отдельная боль. Реактивные подходы частично это решают, но у них своя боль в виде backpressure. По итогу — корутины самый чистый и правильный подход.
> перейдя на более традиционные штуки типа CompletableFuture
Я Вам одну вещь скажу, частенько пласт кода становится более простым и понятным просто потому что его переписывают. А с чего на что переписывают — это не так уж и важно. Но лично я год корутинами пользуюсь в хвост и гриву — но идеи «а может ну его и вернуться к родной лесенке на CompletableFuture» — не возникают ну вот совсем никогда.
Я кстати в начале этого века много подобных историй про классы слышал — вот взяли, навертели в системе классов, а потом все выкинули понаписывали обычных функций и норм стало работать. Корутины — это другая парадигма, и да — её придется научиться понимать, но выгоды слишком велики чтобы ее игнорировать.
Не это главное. «Дубовый» синтаксис джавы это как тяжелый черенок лопаты которой ты копаешь каждый день — через месяц ты его просто не замечаешь. Синтаксис — это роялит в основном при изучении языка, а поскольку мы вроде как профессионалы — то учим язык мы всегда (по времени) меньше чем им пользуемся. Ценность Котлина не в его современном синтаксисе (мы все равно все работаем в IDE и большУю часть дубовости джавы эти IDE скрадывают) — ценность Котлина в том что он умеет в асинхронность. Положите мои слова в банк — через 10 лет языки которые не умеют в асинхронность — будут пылиться в музеях. Да, джава тоже пытается пылить свою асинхронность — но ей это сильно сложнее потому что она тупо сильно старше, кода на ней — горы, и любой чих отзывается болью различных несовместимостей.
Бегло пролистал и так и не нашел — где хоть кто-то вспомнил про асинхронность. Strict nullability и всякие языковые плюшки типа extension functions — это все замечательно, но без этого можно жить, это не дает level up к продуктивности разработки. А вот что дает — это корутины и их порождение flows, которые пабам — работают даже для самой древней джавы поддерживаемой Котлином (1.6? лень лезть смотреть). Т.е. если у вас есть проект на Джаве который вы хотя бы периодически меняете — есть смысл затаскивать туда Котлин вот прямо сейчас, потому что если на обычном синхронном коде Котлин будет +- один в один джава только покороче — то в коде асинхронном код на Котлине будет в разы (!) короче и в разы проще в поддержке. А где, скажите мне, в 21м веке синхронный код? У нас практически вся бизнес-логика — это микросекунду считаем что делать а потом сотни миллисекунд лезем в базу или сеть — и вот эти вот асинхронности Котлин решает КАРДИНАЛЬНО лучше. Да, в джаве пилят свою асинхронность — но ребята, жизнь коротка, ждать еще 2 года пока они ее допилят да пока ваш проект начнет на нее перелазить — нууу… выбор за вами.
Это не WiFi-модуль, это Orange Pi Zero, китайский одноплатник класса RPI ZeroW - чемпион по дешивизне среди одноплатников (< $10 в розницу с доставкой из Поднебесной). Вообще прикольный бизнес - взять одноплатник за 8 баксов, добавить корпус и DAC (еще баксов на 20 в сумме), написать прошивочку и продавать это за 150-200. Не-не не подумайте - я рад за ребят что они нашли свою нишу и решение придумали простое и экономически выгодное, раз люди покупают - то оно им нужно, но если конкретно вы хотите поковыряться в потрохах линукса на одноплатнике - то все это можно собрать чуть не на порядок дешевле.
Абсолютно нормальный аргумент. Если фича стоит дорого а нужна паре человек — то вполне нормально от нее отказаться.
Конечно быстрее не выполнится, но зато — мы явно видим где наш код может затупить надолго. И это хорошо и правильно, ПМСМ конечно же. Да, я помню что в самом начале использования корутин саспенды расползались по коду как тараканы на свету — но это быстро проходит, чутка опыта — и с этим можно жить.
Как минимум — оно дает понимание что вот в этом конкретном месте программы, где мы вызываем suspendable функцию — программа может воткнуть и вернуться к исполнению через секунды и минуты. Это легче читается чем код в котором функции которые будут работать милисекунды и код который может вызвать запрос на гигабайт через пол-планеты — выглядят одинаково (как в каком-нить олдовом RPC).
> Навскидку, вам под suspendable придется переписать весь стек до самого низкого уровная I/O и JDBC
Да, если у меня в коде есть вызов функции которая начнет синхронно читать файл в гигабайт через пол-планеты — то у меня все воткнёт. Ну так мы в самом начале пути, библиотечные вызовы внутри которых могут быть такие вот радости — мы можем вынести в отдельные потоки и играться с ними там, благо делается это на тех же flows в пол-пинка. А со временем все больше и больше API будут становиться полностью асинхронными (потому как тренд это нынче, не пишут сейчас чисто блокирующих API), и радостей будет только больше.
то для того чтобы понять типы переменных — надо возить мышкой. Так что частенько прописываешь тип даже если он не особо тут нужен — чтобы было за что глазу зацепиться.
А вот корутины это да, мне скоро Джетбрейнс стипендию назначит за то что я их нахваливаю, так что на Джаву теперь ни-ни, я за год ни одного листенера не написал и больше не собираюсь ;)
Эм… Так это ж фича а не баг. Действительно надо понимать где код suspendable а где нет. И да, изменение тяжелое — но этот геморрой стоит свеч, особенно когда доходишь до flows и начинаешь их понимать. Нам не нужны стейтмашины. Нам не нужны листенеры. Мы можем асинхронно запускать кучу зависимых друг от друга задач в параллель не переживая ни о том что это сложно будет останавливать случись чего, ни о том что мы переусложняем логику поведения настолько что это невозможно будет потом сопровождать. Это другая парадигма, но её изучение окупается сторицей — единожды это раскурив ты получаешь левел-ап, и твой код никогда не будет прежним.
Я Вам одну вещь скажу, частенько пласт кода становится более простым и понятным просто потому что его переписывают. А с чего на что переписывают — это не так уж и важно. Но лично я год корутинами пользуюсь в хвост и гриву — но идеи «а может ну его и вернуться к родной лесенке на CompletableFuture» — не возникают ну вот совсем никогда.
Я кстати в начале этого века много подобных историй про классы слышал — вот взяли, навертели в системе классов, а потом все выкинули понаписывали обычных функций и норм стало работать. Корутины — это другая парадигма, и да — её придется научиться понимать, но выгоды слишком велики чтобы ее игнорировать.