Erlang/OTP *

Я являюсь в России одиноким поклонником языка программирования Elixir. Почему я делаю такой пессимистичный вывод.

В России язык Elixir не пользуется популярностью:

·         русскоязычные сайты, посвященные Elixir, постепенно умирают или уже умерли;

·         вакансий программистов Elixir я не встречал, (видел только на Украине);

·         статьи по Elixir в русскоязычном сегменте Internet в основном переводные;

·         переведенных на русских язык книг по Elixir всего две:

1.     для начинающих “Введение в Elixir” С. Сенлорен и Д. Эйзенберг

2.     достойная книга “Elixir в действии» Саши Русич.

Обе книги были переведены издательством ДМК.

Язык Elixir является молодым языком, но считается быстроразвивающимся. На Западе, судя по форумам, у него появилось много сторонников. Но оказалось, что и там вакансий для программистов Elixir очень мало: видел объявление о вакансии, на которую претендовало несколько сотен кандидатов.

Всё это заставляло меня часто задумываться о перспективах Elixir. И возможно, я понял в чем дело. Далее я выражаю своё субъективное мнение о назначение этого языка.

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

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

Привет, Хабр!

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

В статье рассмотрим два языка программирования, которые выделяются своим функциональным подходом и широким применением в микросервисной архитектуре: Scala и Erlang.

Привет, Хабр!

История Erlang 80-х годах прошлого века в стенах шведской компании Ericsson. Он был разработан первоначально для нужд телекоммуникаций, Erlang задумывался как инструмент для создания распределенных, отказоустойчивых систем с возможностью быстрого обновления кода. :

В этой статье кратко рассмотрим его синтаксис и основные возможности.

На этих выходных я написал статью о том, что хочу сделать новый язык для 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. Но я позволил себе немного пофантазировать - надеюсь, попал в цветовую гамму плюс-минус :)

В этой короткой статье я хочу поделиться о том как получить RCE на системе с установленной CouchDB на большинстве инсталляций в локальной сети или во внешней сети, не защищенных брандмауэром. Для справки, в Shodan таких нашлось около полутора тысяч.

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

Самое время рассмотреть “достаточно хороший” алгоритм для борьбы с Poison Message. Здесь будет уже специфика RabbitMQ и к Apache Kafka она не применима, точнее применима только частично - но это уже совсем другая история.

Я участвую в проекте, в котором очень интенсивно используется брокер сообщений RabbitMQ. Под "очень интенсивно" я подразумеваю, что это единственный канал взаимодействия десятков сервисов - никаких вам HTTP и REST. И в этой статье мы рассмотрим понятие "Poison Message" и как с ним можно жить.

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

В команде мы активно используем 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() для дальнейшего использования и создать соответствующую документацию для пользователей нашего нового модуля.

Для протокола: заголовок я позаимствовал у Цицерона, в Oratio in Catilinam Prima in Senatu Habita.

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