gleam - это новый язык со статической типизацией для платформы BEAM (Erlang). Уверен, что Вас он тоже заинтересует - в том случае, если Вы эрлангист, эрланговед или что-то в этом роде. Язык очень любопытный: например, в нём есть зарезервированное слово todo - для мотивации программистов. И, наоборот - отсутствует ключевое слово if.
В целом, gleam - пример того, как эрланг можно переделать для использования с типами. Мы с вами знаем, что есть функциональные языки, такие как Haskell и OCaml, которые работают с типами хорошо. Однако, языки ML-семейства выглядят совсем по-другому. gleam же имеет C-подобный синтаксис.
В этой статье я постарался описать основные черты языка gleam. Также, в конце читателя ждёт увлекательный мастер-класс о том, как (не) нужно превращать обычный императивный язык в функциональный. На примере Python.
И да, поросёнок - не совсем официальный mascot языка gleam. Но я позволил себе немного пофантазировать - надеюсь, попал в цветовую гамму плюс-минус :)
Привет! Меня зовут Наталья. В Каруне я пишу в команде высоконагруженные сервисы на Elixir.
Это третья компания, в которой я работаю на Elixir. До этого я писала на Ruby. Если посмотреть свежее исследование Хабр Карьеры по зарплатам, можно увидеть — зарплаты рубистов растут, а Elixir там нет. Более того, есть истории о том, как люди возвращались с Elixir обратно на Ruby. Я считаю, что на это сильно влияет вход в язык. Elixir классный, но в первые месяцы знакомства с ним мне самой так не казалось. Настолько классный, что я не хочу назад. В этой статье я расскажу про трудности перевода перехода.
Привет, Хабр! Меня зовут Иван, я — техлид в Каруне.
В команде мы активно используем Elixir в одном из самых нагруженных проектов.
Мы уделяем особое внимание тому, что за код выполняется в коллбеках GenServer'а, особенно если это код третьесторонних библиотек.
В этой статье я расскажу, почему это настолько важно, и продемонстрирую, как с помощью простейших механизмов, которые предоставляют нам Elixir и Erlang, мы можем сломать поведение GenServer'a и породить трудноуловимые баги. Ещё расскажу, как мы боролись с таким багом в реальной жизни.
Поехали!
Photo by Science in HD
Если вам когда-либо приходилось решать задачу отправки SMS из кода вашего приложения, скорее всего, вы использовали готовое REST API поставщика дополнительных услуг. Но что происходит после того, как поставщик получит ваш запрос? Какие протоколы используются и какой путь проходит текст сообщения, прежде чем оказаться на экране мобильного терминала пользователя?
В этой статье вы найдёте:
Чего тут точно нет, так это информации по отправке коротких сообщений через SIGTRAN.
Становится уже доброй традицией — все любопытное, что появилось на Хаскеле — повторять на Эликсире.
Первой ласточкой были «Примерно 20 строк для подсчета слов», появившиеся как алаверды на «Побеждая C двадцатью строками Haskell: пишем свой wc» от 0xd34df00d — сегодня же я наткнулся на «Перевозим волка, козу и капусту через реку с эффектами на Haskell» от iokasimov и тоже не устоял.
Итак, встречайте: ленивый полный асинхронный параллельный перебор против алгебраических эффектов.
Практически каждое успешное бизнес-приложение рано или поздно вступает в фазу, когда требуется горизонтальное масштабирование. Во многих случаях можно просто запустить новый экземпляр и уменьшить среднюю нагрузку. Но бывают и менее тривиальные случаи, когда мы должны обеспечить, чтобы разные ноды знали друг о друге и аккуратно распределяли рабочую нагрузку.
Так удачно получилось, что erlang, который мы выбрали за приятный синтаксис и хайп вокруг, имеет первоклассную поддержку для распределенных систем. В теории это звучит вообще тривиально:
Передача сообщений между процессами на разных узлах, а также между ссылками и мониторами прозрачна […]
Полгода назад Крис Пеннер опубликовал Beating C With 80 Lines Of Haskell: Wc. В предисловии говорится:
Задача состоит в том, чтобы построить более шустрый клон оптимизированной вручную реализации утилиты wc на C в нашем любимом высокоуровневом языке программирования со сборкой мусора — на Haskell! Звучит достаточно просто, не так ли?Крис прошел весь путь от простой реализации при помощи ByteStrings, через моноиды, встроенные моноиды и, наконец, пришел к параллельной многоядерной версии вышеописанного, которой и удалось немного побить чистый C-код во время выполнения на четырех ядрах.
Несколько дней назад на Хабре была размещена еще одна заметка на ту же тему от 0xd34df00d Побеждая C двадцатью строками Haskell: пишем свой wc. Автор доказал возможность пользования идиоматического хаскеля и в 20 (двадцати) строках кода реализовал алгоритм, который почти в десять раз быстрее, чем идиоматическая реализация на C.
Elixir снабжен сложной, очень хорошо продуманной, инфраструктурой макросов. С легкой руки Криса Маккорда, в сообществе существует негласный закон, который неизбежно озвучивается сразу, как только речь заходит о макросах: «Первое правило использования макросов — вы не должны их использовать». Иногда с малозаметной ремаркой, набранной бледно-серым шрифтом четвертого кегля: «только если вам этого не избежать, и вы очень хорошо понимаете, на что идете, и чем рискуете». Это связано с тем, что макросы имеют доступ ко всему AST модуля, в котором они используются, и, вообще говоря, могут до неузнаваемости изменить получившийся код.
Я в принципе согласен, что не следует использовать макросы в процессе ознакомления с языком. Пока вы не можете, будучи разбуженным в три часа ночи с похмелья, ответить на вопрос, выполняется ли этот код на стадии компиляции, или же в рантайме. Elixir — компилируемый язык, и в процессе компиляции происходит выполнение кода «верхнего уровня», полное раскрытие синтаксического дерева до тех пор, пока мы не окажемся в ситуации, когда дальше раскрывать уже нечего, и вот этот результат в конечном итоге и компилируется в BEAM. Когда компилятор встречает вызов макроса в исходном коде, он полностью раскрывает AST для него и впихивает вместо собственно вызова. Понять это невозможно, это можно только запомнить.
Все наши микросервисы, вне зависимости от того, как они общаются друг с другом, предоставляют своего рода heartbeat интерфейсы, чтобы система мониторинга могла в любой момент узнать, как там дела; типа общего состояния здоровья и каких-то специфичных частностей, скажем, контрольных сумм для внутренних данных, с которыми они имеют дело. Речь не про основной транспорт: тут прекрасно справляются RabbitMQ и Redis.
А еще иногда имеет смысл предоставить простейший (HTTP) интерфейс для экспорта актуальных данных. Думая и в этом направлении тоже, в долгосрочной перспективе я хочу полностью избавиться от Redis в пользу внутреннего решения для хранения пар ключ-значение, как мы успешно сделали ровно два года назад с PubSub.
Поэтому вместо того, чтобы заново изобретать велосипеды с каждым новым микросервисом, я решил создать подключаемую библиотеку, которая могла бы решать эту бесхитростную проблему по предоставлению произвольных данных из любого приложения с нулевым кодом (если не считать трех строчек в config.exs). Будь то простой heartbeat (HTTP 200 OK), или длинный список актуальных курсов валют.
Решение основано на этом твите Дэйва Томаса.
OTP расшифровывается как Open Telecom Platform; так исторически сложилось, потому что платформа создавалась для нужд и на деньги Ericsson. Но, в принципе, это название имеет примерно столько же коннотаций с ее функциональностью, сколько и яблоки со среднего качества телефонами.
Основной отличительной характеристикой OTP по замыслу авторов является отказоустойчивость. Не многопоточность, не модель акторов, не богатые возможности pattern matching’а, даже не прозрачная кластеризация и не hot code upgrades. Отказоустойчивость.
Виртуальная машина эрланга на поверхностный взгляд устроена очень просто: есть куча «процессов» (не системных процессов, эрланг-процессов) с изолированной памятью, которые могут обмениваться сообщениями. Все. Вот, что говорил Джо Армстронг по этому поводу:
In my blog I argued that processes should behave pretty much like people. People have private memories and exchange data by message passing.
— Why I don't like shared memory
Обмен сообщениями внутри OTP очень прост: один процесс посылает сообщение другому (или группе других процессов), синхронно, или асинхронно. Но для этого необходимо знать, кому эти сообщения посылать. То есть менеджером обмена выступает отправитель. Но что если мы хотим просто слать broadcast и дать возможность всем заинтересованным процессам подписаться на это сообщение?
def notify?(rate) when rate > 2.0, do: true
def notify?(_), do: false
В 2016-м году я опубликовал перевод статьи про 5 перспективных языков программирования, в которой прогнозировался их рост в ближайшие 2-3 года.
Зачастую прогнозы так и остаются прогнозами, без последующего анализа. Но я решил, что это непорядок. И посколько 3 года уже пролетели, пора подвести промежуточные итоги и посмотреть, что произошло с этими языками за это время.
Однако, прежде чем мы перейдём к пятёрке наших героев, хочется уделить немного внимания предсказанному в той же статье переходу Swift и Go из второго эшелона в первый.
В исходной статье языки программирования условно делятся на 3 эшелона по популярности.
Первый эшелон включает мейнстрим-языки, такие как Java, JavaScript, Python, Ruby, C# и т.д.
Языки второго эшелона пытаются пробиться в мейнстрим, но ещё не добились этого. Они доказали свою состоятельность путем создания сильных сообществ, но они до сих пор не используются большинством консервативных IT-компаний. Большинство языков в первом эшелоне прочно укоренились на своих позициях. Поэтому выпадение языка с лидирующих позиций занимает ощутимое время, а для языка второго эшелона очень трудно пробиться в первый.
К третьему эшелону относятся непопулярные языки, а также относительно новые перспективные языки (о которых пойдёт речь), которые только начинают свой путь наверх. Некоторые языки пребывают в третьем эшелоне на протяжении многих лет, не получая популярности, в то время как другие врываются на сцену всего за пару лет.
Не так давно 12.12.2018 был анонсирован выход новой библиотеки для фанатов phoenix framework под названием Phoenix LiveView. Я бы хотел поделиться с вами впечатлениями от ее использования и phoenix в целом, а в следующей статье попробовать написать простую браузерную игру. Часть статьи с личным мнением не является исключительно правдивой, я попробую объяснить преимущества веб-разработки на примере phoenix против php
В последние несколько дней на Хабре был опубликован ряд статей, общим лейтмотивом которых (особенно в комментариях) стало противостояние тупоконечников с остроконечниками – адепты ФП против ООП, хотя их и призывали не спорить. Иногда обсуждали Erlang, в связи с чем мне вспомнился короткий пост на тему от Джо Армстронга, одного из создателей этого языка, написанный им в конце 2018 года на форуме по Elixir в ответ на вопрос о парадигме языка. Думаю, его комментарий будет интересен.
Как реализовать на Эликсир JSON API endpoint без каких либо фреймворков?
От переводчика:
В статье приведён пример очень простого веб-приложения, которое можно рассматривать как Hello, World! в создании простейшего API на Эликсире.
Код примера незначительно изменён для того, чтобы соответствовать текущим версиям библиотек.
Полный код примера с изменениями можно увидеть на GitHub.
Многие разработчики приходят в Эликсир из мира Ruby. Это очень зрелая среда с точки зрения количества доступных библиотек и фреймворков. И такой зрелости мне иногда не хватает в Эликсире. Когда мне нужна сторонняя служба, результат поисков подходящей может быть следующим:
