До конференции RubyRussia осталось совсем немного времени.
У тех, кто не успел получить билет, еще есть возможность забрать его по адресу: г.
Веб-сайт один из последних.
Никита Шильников на конференции расскажет об алгебраических эффектах, а пока вы можете прочитать интервью по теме доклада.
Расскажи, чем ты занимаешься и какое отношение это имеет к Ruby?
Я работаю в двух компаниях, проекты которых написаны на Ruby. В одном мы занимаемся биллингом, можно сказать, что это полупредприятие, а в другом создаем SaaS-сервис.
Так получилось, что я много работаю с открытым исходным кодом.
Четыре года назад я заинтересовался одним проектом, нашел в нем некоторые недостатки функционала, решил их исправить и понеслось.
Сейчас я являюсь основным разработчиком двух организаций и сообщества.
Все можно увидеть у меня Гитхаб .
Одна часть работы касается баз данных.
ром-рб , и другие сухой-рб представляет собой набор библиотек на разные случаи жизни.
В своем отчете об алгебраических эффектах расскажите нам, какую пользу они приносят разработчикам.
Здесь необходим небольшой обзор.
Косистема Dry-RB основана на функциональном программировании.
Но во время его разработки что-то не давало мне покоя.
Например, вы разрабатываете SaaS-сервис и стоит простая задача по изоляции данных.
Вроде бы все понятно, есть какой-то сервис, в нем зарегистрированы компании, и они не должны иметь доступа к данным друг друга.
Решить ее можно разными способами.
Но с чисто функциональной точки зрения я не нашел ответа, как это сделать, кроме явной передачи аргументов по всему коду.
Я придумал свое «нефункциональное» решение и жил с ним.
В конце 2018 года в React появились хуки.
Когда я впервые увидел их API, я подумал, что такие вещи нельзя сделать так просто.
Я прекрасно представляю, как работает JavaScript, и решил, что здесь явно не все чисто, используются глобальные переменные или что-то еще.
В моем понимании работы программы это было либо невозможно, либо использовался какой-то грязный хак.
Я решил изучить этот вопрос.
Оказалось, что я не единственный человек, которого интересовала эта тема.
Я нашел информацию, что существует такой способ формализации, то есть написания программ, которые как бы используют глобальные переменные или какое-то общее состояние.
Однако они все равно останутся чистыми.
Проблема была срочной, и я начал копать глубже.
В результате ответом стали те самые алгебраические эффекты.
Я написал небольшой прототип на Ruby, и, к моему удивлению, все заработало.
Я внедрил его в продакшен, запустил и несколько месяцев погонял, потом сделал решение для всех.
Вы действительно заинтриговали меня хуками React. Я думал, что есть что-то очень простое, например, стек вызовов, замыкания, текущая область видимости.
Это действительно так.
Проблема в том, что у вас есть какая-то статья, в которой описывается семантика и то, как с научной точки зрения это должно работать.
Если следовать спецификации, то можно сделать библиотеку.
В случае с React — это тоже библиотека или, скажем, фреймворк, предоставляющий какой-то API. Если правильно им пользоваться, все работает отлично.
Но если пойти налево или направо, это может закончиться плохо.
В React просто запретили использование хуков в условиях.
Они должны были это сделать.
Это одно из ограничений.
Имеет ли это какое-либо отношение к математическому доказательству правильности кода? Не совсем.
Вопрос здесь не в том, что нужно что-то доказывать, вопрос больше в сторону проверки программы.
То, о чем говорят алгебраические эффекты, — это просто описание семантики.
Это ничего не доказывает, но показывает, как это должно работать.
Если эта библиотека, реализующая алгебраические эффекты, сама по себе не содержит ошибок, то, описывая семантику, вы гарантируете, что ваш код будет работать так, как задумано.
Что вы думаете о типах и статически типизированных языках программирования? Очень позитивно.
Например, у нас есть бэкенд на Ruby и фронтенд на чем-то вроде ReasonML. Это OCaml, но с другим синтаксисом.
При прочих равных я выбираю именно эту систему типов.
Это довольно просто и существует ряд языков, имеющих подобную или подобную реализацию.
Чем больше типов, тем лучше.
Параллельно пишу бэкенд на Ruby и меня все устраивает. Я разработчик инструментов, с которыми работаю, и они всегда касались типов: сухие типы , сухая структура , сухая схема , сухая проверка , сухие монады .
Речь идет об описании типов, которые поступают из базы данных, от пользователя, из внешних систем.
Чтобы вы всегда знали, с чем работает ваш Ruby-код. Даже если она сама не типизирована, вы точно можете быть уверены в типе переменной, с которой работаете.
Ходят слухи, что у Ruby 3 будут типы.
Что вы скажете по этому поводу? У меня есть опыт работы с Python. Когда типы туда завезли, тулинг был не очень развит и меня это не впечатлило.
Сейчас ситуация там лучше.
Вы можете пойти туда и описать все типами и использовать какую-то настройку, которая проверит корректность вашей программы.
Речь идет о какой-то замене компилятора, о том, что сейчас за нас делает sorbet. В Python это заняло несколько лет. Я всегда приветствую движение к типажам, но иллюзий не питаю.
Вы смотрели на новый синтаксис, который планируется реализовать в коде Ruby? Я особо не играл, зашёл в чат и посмотрел.
Но у меня нет мнения, как это должно быть реализовано.
Синтаксис можно улучшить, изменить язык и так далее.
Теперь они сделали обычный Ruby-совместимый синтаксис.
Я не думаю, что синтаксис здесь является камнем преткновения, камнем преткновения здесь являются инструменты, и, как я уже сказал, это очень долгий путь.
Что еще вы хотели бы видеть в Ruby, учитывая его развитие? Меня бы заинтересовала кооперативная многозадачность.
У нас уже есть кооперативная многозадачность в виде оптоволокна.
Нам до сих пор не хватает возможности запускать их в нескольких потоках.
Есть варианты, как это будет сделано, и не совсем понятно, в какой форме.
Учитывая, что реализации Ruby и C имеют довольно солидное наследие, Matz не хочет нарушать обратную совместимость.
Я склоняюсь к комбинации волокон и нескольких потоков, работающих одновременно.
Может быть, что-то вроде «Гильдии» сработает. Юкихиро Мацумото, автор Ruby, приедет на конференцию в этом году.
Что бы вам было интересно обсудить с ним за чашечкой кофе или бокалом сакэ на after-party? Лучшее, что мы можем сделать при общении с авторами языков или даже библиотек — показать им, как мы используем этот продукт в реальной жизни.
И даже в таком смысле, которого авторы не ожидали.
Это даст автору возможность учесть подобный опыт и применить его в дальнейшей разработке.
Я хотел бы показать всю историю с алгебраическими эффектами.
Я бы сказал – посмотрите, какие вещи можно сделать на том чудо-языке, который вы создали.
И, возможно, после этого он придумает для нас что-нибудь еще.
До встречи на RubyРоссия! Напомним, конференция уже в эту субботу, Регистрация Все еще открыт. Будут не только доклады, но и стенды лучших компаний: Организатор - Еврон Генеральный партнер - Топтал Золотой партнер - Гетт Серебряные партнеры - Валарм , JetBrains , букмекер И Кэшвагон Бронзовый партнер - В продаже Теги: #Интервью #Конференции #конференция #ruby #ruby onrails #интервью #ror #railsclub #railsclub #railsclub #railsclub #rubyrussia #rubyrussia
-
Sape: Теперь Не Только Ссылки, Но И Статьи
19 Oct, 24 -
Спам От Yo-Auto
19 Oct, 24 -
Животные Или Зомби
19 Oct, 24
