Elixir/Phoenix *

Сегодня поговорим с вами о теме распределённых вычислений на Elixir. Мы больше не можем позволить себе писать приложения, которые работают только на одной машине. Пришло время создавать системы, которые могут выдержать любую нагрузку и работать бесперебойно даже в случае выхода из строя отдельных компонентов.

Elixir — это язык программирования, который вырос на основе мощной виртуальной машины BEAM, используемой в Erlang. Это сразу даёт нам ряд фич: хорошую масштабируемость, встроенную поддержку конкурентности и возможность строить распределённые системы.

В этой статье мы рассмотри основные инструменты для реализации распределённых вычислений Elxir.

Я фулстек-разработчик, индивидуальный предприниматель. По моему опыту, один из самых востребованных классов проектов, за разработкой которых к нам обращаются, — приложение для работы в режиме реального времени. Конечно, вам такие приложения известны: WhatsApp, Discord, Slack, т.д. При разработке приложений для работы в режиме реального времени следует учитывать различные факторы, в частности, масштабируемость, отказоустойчивость, отзывчивость и распределённость. Это задача не из лёгких, в особенности для небольшой команды или разработчика‑одиночки.

Но что если бы я вам сказал… что можно создавать приложения для работы в режиме реального времени, которые можно масштабировать более чем на миллион пользователей силами всего нескольких разработчиков? К тому же, такие приложения можно было бы развёртывать почти без задержек и ценой минимальных затрат. Здесь я имею в виду, что для этого нужно освоить секретное оружие под названием «Виртуальная машина Erlang» или BEAM (Абстрактная машина Богдана/Бьёрна для языка Erlang).

Стек технологий для запуска нового продукта в компании обычно выбирается исходя из того, с чем команда работала до этого и сколько наработок уже имеется.

Однако если вы свободны от необходимости использования какого-либо наследия (набираете новую команду или ищете актуальные технологии для изучения), то эта статья поможет вам выбрать, что стоит использовать для запуска продукта или сервиса. 

Меня зовут Евгений Корнеев и я постараюсь дать разностороннюю оценку с точки зрения зрелости технологии, популярности, доступности специалистов и вакансий, а также того, для каких целей лучше применять конкретный стек.

По долгу службы, мы много работаем с деньгами. Складываем, вычитаем, считаем проценты. Любому школьнику известно, что для этих расчетов не подходят обычные встроенные в язык типы: флоаты не сойдутся у финансовых аудиторов, большие целые принесут кучу проблем при конвертации (например, йены обходятся без дробных единиц, а в одном оманском риале — 1000 баиз, а не сто, как у всяких плебейских долларов и евро), и так далее. Существуют целые комитеты, определяющие стандарты (ISO 4217 — коды валют и ISO 24165 — идентификаторы цифровых токенов). Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности.

В мире эликсира, почти всем, что связано с имплементацией комитетских стандартов, занимается Кип Коул. Удобной работе с деньгами мы обязаны тоже его библиотекам: ex_money — для собственно арифметики и money_sql для персистенса.

На этих выходных я написал статью о том, что хочу сделать новый язык для BEAM со статической типизацией. И получил объёмный фидбэк - большая часть его содержалась, как обычно, между строк. Теперь хочу вам представить издание 2е, полностью переработанное.

Новый план состоит в том, чтобы использовать синтаксис Elixir как он есть (да!) Ну, разве что, типы в него добавить. Также, нужно сделать соответствие модулей и физических файлов 1:1.

UPDATE: berry будет поддерживать макросы, но только импортируемые. use поддерживаться не будет.

import Ecto, macros: [from]

Таким образом, фанатам Ecto беспокоиться не о чём. Вы хотите спросить, не хочу ли я поделиться этой идеей с более широким сообществом? Я уже сделал это! А вот, какая была реакция - об этом читайте под катом.

Привет! Сегодня хочу поделиться идеей нового языка для платформы BEAM: читатели хабра всё должны узнавать из первых рук! Планируется, что он будет транслироваться в эрланг source-to-source, и семантически будет тоже максимально совместим с эрлангом.

berry-lang поддерживает статическую типизацию, однако типы в нём - не главное. Главное - это приятный синтаксис, о чём свидетельствует его ягодное название. Кстати, о названии: помимо того, что оно созвучно слову Erlang, у него есть и другая подоплёка.

Дело в том, что berry-lang крадёт весь свой синтаксис у языка Сyber (слышали о таком?) Получается - кибер-тема. А чем заняты в кибер-городе? Выращиванием ягод, конечно! Скриншот - из последней Матрицы, на нём генерал Найоби угощает Нео клубникой и говорит, не без гордости - "Zion could have never made something like this!".

Статья содержит много коротких примеров с кодом! Будет интересна всем поклонникам языка эрланг и платформы BEAM. А если о языке Сyber ничего не слышали, то вообще - must-see.

Вы когда‑нибудь замечали, что pattern matching и Dependency Injection чем‑то похожи? Я — да. Вообще, pattern matching, характерный для функциональных языков, матчит значения только по структуре и содержимому. Вызовы функций не разрешаются. Я подумал — что, если разрешить вызовы функций? В этом случае, мы получим нечто близкое к Dependency Injection.

MiddleAges(status, lifespan) = hipster

Вот так можно попробовать сматчить хипстера, отправив его в средневековье — чтобы узнать социальный статус, который он там займёт, а также его время жизни там. MiddleAges — это некоторая функция. Можно оставить слева только status или только lifespan, хотя, конечно, всем любопытно узнать и то, и другое. Похоже ведь на Dependency Injection?

В этой статье я попытался представить себе, как бы мог выглядеть функциональный язык, основанный на таких конструкциях. Спойлер: в нём есть оператор pop.

gleam - это новый язык со статической типизацией для платформы BEAM (Erlang). Уверен, что Вас он тоже заинтересует - в том случае, если Вы эрлангист, эрланговед или что-то в этом роде. Язык очень любопытный: например, в нём есть зарезервированное слово todo - для мотивации программистов. И, наоборот - отсутствует ключевое слово if.

В целом, gleam - пример того, как эрланг можно переделать для использования с типами. Мы с вами знаем, что есть функциональные языки, такие как Haskell и OCaml, которые работают с типами хорошо. Однако, языки ML-семейства выглядят совсем по-другому. gleam же имеет C-подобный синтаксис.

В этой статье я постарался описать основные черты языка gleam. Также, в конце читателя ждёт увлекательный мастер-класс о том, как (не) нужно превращать обычный императивный язык в функциональный. На примере Python.

И да, поросёнок - не совсем официальный mascot языка gleam. Но я позволил себе немного пофантазировать - надеюсь, попал в цветовую гамму плюс-минус :)

Привет, это очередной доклад Ruby Russia 2022. В нём наш разработчик Дмитрий Клейменов рассказывает, как он восемь лет пытался сменить Ruby на Elixir, благодаря чему ему все же это удалось, и жалеет ли он о переходе в другой стек.

Привет! Меня зовут Наталья. В Каруне я пишу в команде высоконагруженные сервисы на Elixir.

Это третья компания, в которой я работаю на Elixir. До этого я писала на Ruby. Если посмотреть свежее исследование Хабр Карьеры по зарплатам, можно увидеть — зарплаты рубистов растут, а Elixir там нет. Более того, есть истории о том, как люди возвращались с Elixir обратно на Ruby. Я считаю, что на это сильно влияет вход в язык. Elixir классный, но в первые месяцы знакомства с ним мне самой так не казалось. Настолько классный, что я не хочу назад. В этой статье я расскажу про трудности перевода перехода.

Облачные сервисы уже давно стали неотъемлемой частью нашей жизни. На данный момент существует большое количество сервисов от разных компаний. Так давайте разберемся в принципах работы простейшего облачного сервиса, подтянем навыки проектирования систем. Данный проект можно постоянно развивать на протяжении длительного времени, и может стать отличным pet project. Созданное облако может пригодится для управления домашними файлами, достаточно его развернуть в локальной сети и с легкостью получать доступ к файлам с разных устройств.

Прыгайте под кат за подробностями.

Привет, Хабр! Меня зовут Иван, я — техлид в Каруне.

В команде мы активно используем Elixir в одном из самых нагруженных проектов.

Мы уделяем особое внимание тому, что за код выполняется в коллбеках GenServer'а, особенно если это код третьесторонних библиотек.

В этой статье я расскажу, почему это настолько важно, и продемонстрирую, как с помощью простейших механизмов, которые предоставляют нам Elixir и Erlang, мы можем сломать поведение GenServer'a и породить трудноуловимые баги. Ещё расскажу, как мы боролись с таким багом в реальной жизни.

Поехали!

Вот в чём вопрос! Что лучше - держать всё в одном процессе, или создавать отдельный процесс на каждый кусок состояния, которым нам нужно управлять? В этой статье я немного расскажу об использовании или неиспользовании процессов. Я также расскажу, как отделить сложную логику с отслеживанием состояния от таких проблем, как временное (темпоральное) поведение и межпроцессное взаимодействие.

Но перед тем, как начать, т. к. статья будет длинной, я хотел бы обозначить основные моменты:

• Используйте функции и модули для разделения мыслительных сущностей.

• Используйте процессы для разделения сущностей времени выполнения.

• Не используйте процессы (даже агентов) для разделения сущностей мышления.

Конструкция "мыслительные сущности" здесь относится к идеям, которые есть в нашем разуме, таким как "заказ", "позиция в заказе", "продукт" и т. д. Если эти концепции слишком сложны, то стоит реализовать их в отдельных модулях и функциях для разделения различных сущностей и держать каждую часть нашего кода сфокусированной и целостной.

Использование для этого процессов (например агентов) - это ошибка, которую люди часто допускают. Такой подход существенно упускает функциональную составляющую Elixir и вместо этого пытается имитировать объекты процессами. Реализация, скорее всего, будет хуже, чем простой функциональный подход (или даже эквивалент на языке объектно-ориентированного программирования). Поэтому стоит обращаться к процессам, только когда есть ощутимые выгоды от этого. Организация кода не входит в число этих преимуществ, так что это не лучший повод для использования процессов.

Photo by Science in HD

Если вам когда-либо приходилось решать задачу отправки SMS из кода вашего приложения, скорее всего, вы использовали готовое REST API поставщика дополнительных услуг. Но что происходит после того, как поставщик получит ваш запрос? Какие протоколы используются и какой путь проходит текст сообщения, прежде чем оказаться на экране мобильного терминала пользователя?

В этой статье вы найдёте:

1. Немного теории и терминологии SMPP-протокола: SMSC, ESME, PDU, MO/MT SM.
2. Краткий обзор существующих библиотек для работы с SMPP в Erlang/Elixir.
3. Пример реализации асинхронного клиента при помощи библиотеки SMPPEX. Возможно, он будет полезен тем, кто ещё не использовал Elixir-библиотеки в Erlang-проектах.
4. Информацию по обработке deliver_sm, MO SM.

Чего тут точно нет, так это информации по отправке коротких сообщений через SIGTRAN.

Когда я начинал писать заметку «Типы, где их не ждали», мне казалось, что я осилил принести эрланговские типы в рантайм и теперь могу их использовать в клиентском коде на эликсире. Ха-ха, как же я был наивен.

Все, что предложено по ссылке, будет работать для явных определений типа по месту использования, наподобие use Foo, var: type(). К сожалению, такой подход обречен, если мы хотим определить типы где-нибудь в другом месте: рядом в коде при помощи атрибутов модуля, или, там, в конфиге. Например, для определения структуры мы можем захотеть написать что-то типа такого:

# @fields [foo: 42]
# defstruct @fields

@definition var: atom()
use Foo, @definition

Код выше не то, что не обработает тип так, как нам хочется — он не соберется вовсе, потому что @definition var: atom() выбросит исключение ** (CompileError) undefined function atom/0.

Давайте представим себе реализацию модуля Scaffold, который генерирует структуру с предопределенными пользовательскими полями и инжектит ее в вызываемый модуль при помощи use Scaffold. При вызове use Scaffold, fields: foo: [custom_type()], ... — мы хотим реализовать правильный тип в Consumer модуле (common_field в примере ниже определен в Scaffold или еще где-нибудь извне).

@type t :: %Consumer{
  common_field: [atom()],
  foo: [custom_type()],
  ...
}

Было бы круто, если бы мы могли точно сгенерировать тип Consumer.t() для дальнейшего использования и создать соответствующую документацию для пользователей нашего нового модуля.