Forem: Artyom Molchanov

Ash Framework: Introduction

Artyom Molchanov — Sat, 04 Apr 2026 08:18:54 +0000

When a newcomer starts with Elixir and Phoenix, they are almost always introduced to Ecto first. You create schemas, write changesets, and move queries into contexts. This approach is flexible, but as the project grows, a serious problem begins to emerge 😟

Business logic starts to spread across dozens of files. Eventually, confusion arises about where to place request handling code and how to make sense of the existing mess. After a year or two, it becomes difficult to understand where the “right” place for code is, and new developers spend weeks just getting up to speed with the project.

Ash Framework was created precisely to solve this pain 💪

Important clarification: Ash is not a replacement for Phoenix and not a new web framework. It is a powerful declarative layer that organizes business logic and data on top of the existing ecosystem.

ㅤ

📖 Preface

It’s important to understand that the goal of this article is not to convince you to use Ash everywhere and all the time!

Personally, I love Ash because it allows you to gather all necessary logic in a single space, where it belongs. This tool significantly simplifies work, reducing boilerplate code and freeing you from the tedious implementation of standard CRUD.

If you’re ready to get acquainted with such a tool but plan to use it only when truly justified—read on without hesitation. Ash is not a universal cure-all, but rather a convenient set of useful tools.

ㅤ

🚀 What is Ash?

Ash is a framework for fast and efficient application development in Elixir. Its goal is to simplify launching new projects and make maintaining existing solutions convenient, ensuring excellent performance and stability even after long periods of active development.

The key idea of Ash is:

Precisely define the structure of your business logic, and let Ash handle all the rest (database migrations, API interface creation, data validation, access control, form generation).

The framework integrates beautifully with popular tools like Phoenix, PostgreSQL, GraphQL, and LiveView.

ㅤ

🔑 Key Abstractions in Ash

Everything in Ash is built around three main concepts:

Resource — description of a single business entity
Action — an operation that can be performed on a resource
Domain — logical grouping of resources within one business area

Let’s break down each concept in detail!

ㅤ

🧩 What is a Resource?

Resource is one module where a single business entity of your application (User, Lesson, Order, Post, Payment, etc.) is fully described.

Everything related to this entity is collected in one place:

Data structure (fields)
Relationships with other entities
Operations that can be performed (CRUD + custom)
Validation rules
Authorization (who can do what)
Computed fields
Indexes and constraints
Storage settings in the database

A Resource in Ash unifies in one module what in classic Elixir/Phoenix is usually spread across several parts: Ecto Schema, Changesets, Context functions, as well as authorization logic and computed fields.

ㅤ

Resource — The Heart of Ash

Ash is built around the idea of Resource-Oriented Design. You describe what an entity is and what can be done with it—and Ash generates the rest: SQL queries, APIs, forms, migrations, validation, etc.

ㅤ

Complete Example of a Modern Resource

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource,
    otp_app: :course_hub,
    domain: CourseHub.Courses,
    data_layer: AshPostgres.DataLayer

  # ==================== STORAGE ====================
  postgres do
    table "lessons"
    repo CourseHub.Repo
  end

  # ==================== FIELDS (Attributes) ====================
  attributes do
    uuid_primary_key :id

    attribute :title, :string do
      public? true
      allow_nil? false
      constraints min_length: 3, max_length: 200
    end

    attribute :description, :string, public?: true
    attribute :content, :string, public?: true

    attribute :status, :atom do
      public? true
      default? :draft
      constraints one_of: [:draft, :published, :archived]
    end

    create_timestamp :inserted_at
    update_timestamp :updated_at
  end

  # ==================== RELATIONSHIPS ====================
  relationships do
    belongs_to :author, CourseHub.Accounts.User do
      public? true
      allow_nil? false
    end

    has_many :comments, CourseHub.Courses.Comment do
      public? true
    end

    many_to_many :tags, CourseHub.Courses.Tag do
      public? true
      through CourseHub.Courses.LessonTag
      source_attribute_on_join_resource :lesson_id
      destination_attribute_on_join_resource :tag_id
    end
  end

  # ==================== ACTIONS ====================
  actions do
    defaults [:create, :read, :update, :destroy]

    # Custom read
    read :published do
      filter expr(status == :published)
      pagination offset?: true, countable: true
      prepare build(sort: [inserted_at: :desc])
    end

    # Custom create with logic
    create :publish do
      argument :reason, :string
      change set_attribute(:status, :published)
    end

    # Fully custom action
    action :calculate_reading_time, :integer do
      argument :content, :string, allow_nil?: false
      run fn input, _context ->
        minutes = String.length(input.arguments.content) |> div(500) |> max(1)
        {:ok, minutes}
      end
    end
  end

  # ==================== COMPUTED FIELDS ====================
  calculations do
    calculate :reading_time_minutes, :integer do
      calculation fn records, _context ->
        Enum.map(records, fn lesson ->
          (String.length(lesson.content || "") / 500) |> Float.ceil() |> trunc()
        end)
      end
    end
  end

  # ==================== INDEXES ====================
  identities do
    identity :unique_title_per_author, [:title, :author_id]
  end

  # ==================== AUTHORIZATION ====================
  policies do
    policy action_type(:read) do
      authorize_if always()
    end

    policy action(:update) do
      authorize_if expr(author_id == ^actor(:id))
    end
  end
end

ㅤ

Main Sections of Resource

Section	Describes	Analog in Classic Elixir/Phoenix
`attributes`	Fields and their types + validation	Ecto Schema + fields
`relationships`	Relationships with other resources	Ecto associations
`actions`	All possible operations (CRUD + custom)	Context functions + Changesets
`calculations`	Computed fields (on the fly)	Virtual fields / functions
`aggregates`	Aggregates (count, sum, avg, etc.)	Queries with group_by
`identities`	Unique indexes	Ecto unique constraints
`policies`	Authorization rules	Manual permission checks
`postgres`	PostgreSQL storage settings	Migrations

ㅤ

Key Features of Resource

Everything in one file — a huge plus for understanding the entity.
Introspection — Ash can read all information about a resource at runtime (fields, actions, policies). This is used for API generation, forms, admin panels.
Declarativeness — you describe what should be there, not how to implement it.
Extensibility — you can add your own changes, preparations, validations, notifiers.
Embedded Resources — you can create resources stored not in a separate table but as JSON/Map within another resource.

ㅤ

When to Create a New Resource?

Almost always when a new business entity appears (a table or even a complex JSON object).

ㅤ

🛠️ More About Actions

Action is an explicitly declared operation that can be performed on a resource.
All data interaction in Ash goes only through Actions. You cannot simply take a record and change it manually—you always call an action.

This replaces:

Regular functions in Phoenix Contexts
Changesets in Ecto
Controllers and service layers

ㅤ

Five Types of Actions

	Action Type	What It Does?	In Transaction?	Returns?
✨	`create`	Creates a new record	Yes	New resource record
🔍	`read`	Reads one record or a list	No (can be enabled)	Record or list of records
✏️	`update`	Updates an existing record	Yes	Updated record
🗑️	`destroy`	Deletes a record	Yes	Deleted record
⚡	`action` (Generic)	Any custom business logic	No (can be enabled)	Any value

ㅤ

Complete Example of All Action Types

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource, ...

  actions do
    # 1. Standard CRUD (defaults)
    defaults [:create, :read, :update, :destroy]

    # 2. Custom Read
    read :published do
      filter expr(status == :published)
      pagination offset?: true, countable: true, default_limit: 20
      prepare build(sort: [inserted_at: :desc], load: [:author, :comment_count])
    end

    read :for_user do
      argument :user_id, :uuid, allow_nil?: false
      filter expr(author_id == ^arg(:user_id))
    end

    # 3. Custom Create
    create :publish do
      argument :reason, :string, allow_nil?: true

      # Changes (changes)
      change set_attribute(:status, :published)
      change set_attribute(:published_at, &DateTime.utc_now/0)
      change {CourseHub.Changes.NotifySubscribers, topic: "new_lessons"}

      # Hooks
      after_action fn _changeset, lesson, _context ->
        {:ok, lesson}
      end
    end

    # 4. Custom Update
    update :archive do
      accept [:archive_reason]
      change set_attribute(:status, :archived)
      change set_attribute(:archived_at, &DateTime.utc_now/0)
    end

    # 5. Generic Action (fully custom)
    action :calculate_reading_time, :integer do
      argument :content, :string, allow_nil?: false
      argument :words_per_minute, :integer, default?: 200

      run fn input, _context ->
        minutes = String.length(input.arguments.content) 
                  |> div(input.arguments.words_per_minute) 
                  |> max(1)
        {:ok, minutes}
      end
    end
  end
end

ㅤ

How to Call Actions

# Through Domain (recommended way)
CourseHub.Courses.publish!(lesson, %{reason: "Готово"})
CourseHub.Courses.read!(CourseHub.Courses.Lesson, :published)
# Or with Ash.Query / Ash.Changeset for complex cases
query = Ash.Query.for_read(Lesson, :published)
Ash.read!(query)

ㅤ

Main Capabilities of Actions

1. `argument` — Input Parameters

Allows passing data into an action and validating it.

argument :title, :string, allow_nil?: false, constraints: [min_length: 5]
argument :published_at, :datetime, default?: &DateTime.utc_now/0
argument :user_id, :uuid, allow_nil?: false

2. `accept` — Which Attributes Can Be Changed

Limits the list of fields that can be modified during create or update. Very useful for security.

create :register do
  accept [:email, :password, :name]
end

update :update_profile do
  accept [:name, :bio, :avatar_url]
end

3. `change` — Data Transformations

The most powerful and frequently used part of Actions. Here the main business logic happens.

create :publish do
  argument :reason, :string

  change set_attribute(:status, :published)
  change set_attribute(:published_at, &DateTime.utc_now/0)

  change {CourseHub.Changes.NotifySubscribers, topic: "lessons"}

  change fn changeset, _context ->
    Ash.Changeset.change_attribute(changeset, :slug, generate_slug(changeset))
  end
end

4. `prepare` — Query Preparation (mainly for `read`)

Allows pre-configuring the query: sorting, preloading relations, additional filters.

read :published do
  filter expr(status == :published)

  prepare build(
    sort: [inserted_at: :desc],
    load: [:author, :comments],
    limit: 20
  )
end

5. Hooks (before/after)

Allows executing code before or after an action.

create :publish do
  before_action fn changeset, _context ->
    validate_business_rules(changeset)
  end

  after_action fn _changeset, lesson, _context ->
    LessonNotifier.publish_event(lesson)
    {:ok, lesson}
  end

  after_transaction fn
    {:ok, lesson}, _context -> broadcast_new_lesson(lesson)
    {:error, _}, _ -> :ok 
  end
end

6. `transaction?` — Transaction Management

Determines whether the action should be wrapped in a database transaction.

action :transfer_money, :boolean do
  argument :from_account_id, :uuid
  argument :to_account_id, :uuid
  argument :amount, :decimal

  transaction? true

  run fn input, _context ->
    # complex operation with multiple records
    {:ok, true}
  end
end

7. `pipe_through` — Reusing Logic

Allows creating common pipelines and attaching them to different actions (very useful for DRY).

# In Resource
pipelines do
  pipeline :ensure_admin do
    change ensure_actor_role(:admin)
    validate actor_role(:admin)
  end
end

create :create_admin_content do
  pipe_through :ensure_admin
  accept [:title, :content]
end

update :update_admin_content do
  pipe_through :ensure_admin
  accept [:title, :content]
end

ㅤ

Why Actions Are Awesome?

Full typing and introspection — Ash knows everything about an action at runtime (used for GraphQL, forms, admin panels).
Declarativeness — code reads like business documentation.
Reusability — one action can be used in LiveView, API, Background Job, Tests.
Security — authorization policies are tied to specific actions.
Testability — easy to test individual actions.

ㅤ

Comparison with Classic Elixir/Phoenix

Approach	Where is logic?	Number of files	Clarity
Ecto + Context	Context + Changeset	4–8	Medium
Ash Actions	In one Resource	1	High

Actions are where all your business logic lives.

ㅤ

🏢 What is a Domain?

Domain is a logical container that groups related Resources.
It is similar to Phoenix Context, but much more powerful. If Resource describes one entity (like User, Lesson, Order), then Domain is a "module" or "bounded context" (in DDD terms) that brings together several entities of one business area.

Example:

Accounts — domain for users, profiles, authorization.
Courses — domain for courses, lessons, tests, enrollments.
Billing — domain for payments, subscriptions, invoices.
Therapy — domain for therapy sessions, conversations, messages.

ㅤ

Three Main Goals of Domain

Grouping Resources Organizing the project. Instead of all resources being scattered, they are explicitly grouped into logical units.
Centralized Code Interface Domain allows defining convenient wrapper functions for calling resource actions.
Shared Settings and Cross-Cutting Concerns Here you can set behavior that applies to all resources in the domain (timeouts, default pagination, authorization, etc.).

ㅤ

How Domain Looks in Practice

defmodule CourseHub.Courses do
  use Ash.Domain, otp_app: :course_hub

  # 1. Grouping resources
  resources do
    resource CourseHub.Courses.Course
    resource CourseHub.Courses.Lesson
    resource CourseHub.Courses.Quiz
    resource CourseHub.Courses.Enrollment
  end

  # 2. Code Interface — convenient functions
  define :get_lesson, action: :read, args: [:id], get?: true
  define :list_published_courses, action: :published
  define :enroll_user, action: :create, resource: CourseHub.Courses.Enrollment

  # 3. Shared settings
  execution do
    timeout :timer.seconds(30)
    default_page_size 20
  end

  # Enabling AshAdmin (admin panel)
  admin do
    show? true
  end
end

ㅤ

Why Do You Need Domain?

Organization and boundaries. Clearly separates different parts of the application (like bounded contexts in DDD). Accounts doesn't know about Billing without explicit relations.
Convenient public API. Instead of Ash.read!(CourseHub.Courses.Lesson, ...), you write beautifully:

CourseHub.Courses.get_lesson!(lesson_id)
CourseHub.Courses.list_published_courses!()

Centralized management. You can disable authorization for the entire domain in dev mode, set common policies, notifiers, etc.
Introspection and extensions. Many Ash extensions (GraphQL, JsonApi, Phoenix) work at the domain level.
Testing and isolation. Easier to test one business area as a whole.

ㅤ

Best Practices When Working with Domains

One resource — one domain. A resource cannot belong to multiple domains simultaneously.
How many domains to make?
- Small project → 1–3 domains.
- Medium/large → one per major business area (Accounts, Core, Billing, Notifications, etc.). This helps with scaling and understanding architecture.
Code Interface — a very powerful feature. You can define not only simple wrappers but also those with preset filters, loads, etc.

ㅤ

Comparison: Domain vs Resource

Aspect	Resource	Domain
What it describes	One entity	Group of entities
Where logic lies	Attributes, actions, policies	Grouping + shared settings
Code call	Through domain	Public app interface
Analog in Phoenix	Schema + Context (partially)	Phoenix Context
Quantity per project	Many (one per table)	Few (per business area)

ㅤ

Why Domain Is Especially Useful?

Project grows >10–15 resources.
Complex authorization (policies) needed.
Doing GraphQL / JSON:API / Admin panel.
Team development — everyone needs to understand boundaries.

ㅤ

⚔️ Ash + Phoenix vs Ecto + Phoenix

Aspect	Phoenix + Ecto (classic) 😐	Phoenix + Ash 🔥	Who wins?
Business logic organization	Scattered across Context, Changeset, separate modules	Everything in one Resource	Ash
CRUD operations	Write manually: create, read, update, delete + boilerplate	`defaults [:create, :read, :update, :destroy]` — done ✨	Ash
Authorization	Manual checks / Bodyguard / scopes	Declarative Policies (secure by default) ⚡	Ash
Computed fields	Virtual fields + functions in Context	Calculations — auto-loaded and cached	Ash
Number of files per entity	3–6+ files (Schema + Context + Changeset + Policy)	One file — Resource	Ash
API generation	Absinthe / GraphQL manually + lots of code	`AshGraphql` or `AshJsonApi` — add extension and done	Ash
LiveView forms	Phoenix.Component + manual validation	`AshPhoenix.Form` — forms know everything themselves	Ash
Multi-tenancy	Write yourself (or use schemas)	Built into Policies (attribute-based or context-based)	Ash
Maintainability after 2–3 years	Medium (logic spreads)	High (everything declarative and in one place)	Ash
Development speed	Normal at start	Much faster after learning curve 🚀	Ash
Flexibility	Maximum (full control)	Very high + can escape to pure Ecto when needed	Draw
Learning curve	Easier for beginners	Steeper but pays off in large projects	Ecto

ㅤ

What to Choose in 2026?

Pros of Ash 🔥:

Declarativeness → "Describe the domain — Ash does the rest."
Boilerplate reduction by orders of magnitude ("I write code 3–5 times faster").
Automatic generation of GraphQL, JSON:API, Admin panel, authentication.
Authorization policies and multi-tenancy out of the box.
Excellent maintainability in the long run (exactly what production dreams of). Pros of classic Phoenix + Ecto 😐:
Full control over every byte of code.
Simpler for very small projects and pet projects.
No extra abstraction (if you love "bare" Elixir).
Easier for Elixir beginners. When to choose what?
Small pet project or experiment → pure Phoenix + Ecto.
Medium/large project, SaaS, long-lived app → Phoenix + Ash (huge time and nerve savings).
Want both → you can safely mix in one project (Ash and regular Ecto coexist perfectly).

ㅤ

😴 Conclusion

Ash is not just a library but a shift in approach to Elixir development. It especially shines in medium and large projects where clean architecture, development speed, and long-term maintainability are important.
Of course, it has a learning curve and may be excessive for very simple pet projects. But if you're tired of spreading logic and want a clear declarative structure—Ash gives a very pleasant sense of control over your code.

ㅤ

🙏 From the Author

Thank you very much for your interest in this article! I hope it helped you understand what Ash is and why it's used.
If you liked this article and want more materials like this—join me on my Telegram channel, where I post book reviews, Elixir publications, technical literature, and interesting news!

Ash Framework: Знакомство

Artyom Molchanov — Sat, 04 Apr 2026 08:05:54 +0000

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

Бизнес-логика расползается по десяткам файлов. В итоге возникает путаница относительно того, куда именно поместить код обработки запросов и как разобраться в существующем беспорядке, а через год-два сложно понять, где находится «правильное» место для кода, а новые разработчики тратят недели на погружение в проект

Ash Framework создан именно для решения этой боли 💪

Важное уточнение: Ash — это не замена Phoenix и не новый веб-фреймворк. Это мощный декларативный слой, который организует бизнес-логику и данные поверх существующей экосистемы.

ㅤ

📖 Предисловие

Важно понимать, что цель этой статьи вовсе не состоит в том, чтобы уговорить вас использовать Ash повсеместно и постоянно!

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

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

ㅤ

🚀 Что такое Ash?

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

Ключевая идея Ash звучит так:

Точно сформулируй структуру своей бизнес-логики, а всю остальную работу (миграция базы данных, создание API-интерфейсов, валидация данных, управление доступом, оформление форм) возьмет на себя Ash

Фреймворк прекрасно взаимодействует с такими популярными инструментами, как Phoenix, PostgreSQL, GraphQL и LiveView.

ㅤ

🔑 Ключевые абстракции Ash

Всё в Ash строится вокруг трёх основных понятий:

Resource (Ресурс) — описание одной бизнес-сущности
Action (Действие) — операция, которую можно выполнить над ресурсом
Domain (Домен) — логическая группа ресурсов одной бизнес-области

Давайте разберём каждую концепцию подробно!

ㅤ

🧩 Что такое Ресурс?

Resource — это один модуль, в котором полностью описана одна бизнес-сущность вашего приложения (Пользователь, Урок, Заказ, Пост, Платёж и т.д.).

В нём в одном месте собрано всё, что касается этой сущности:

Структура данных (поля)
Связи с другими сущностями
Операции, которые можно выполнять (CRUD + кастомные)
Правила валидации
Авторизация (кто и что может делать)
Вычисляемые поля
Индексы и ограничения
Настройки хранения в базе

Resource в Ash объединяет в одном модуле то, что в классическом Elixir/Phoenix обычно разносится по нескольким частям: Ecto Schema, Changesets, Context-функции, а также логика авторизации и вычисляемые поля.

ㅤ

Resource — сердце Ash

Ash построен вокруг идеи Resource-Oriented Design. Ты описываешь что представляет собой сущность и что с ней можно делать — а Ash сам генерирует остальное: SQL-запросы, API, формы, миграции, валидацию и т.д.

ㅤ

Полный пример современного Resource

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource,
    otp_app: :course_hub,              # Привязка к приложению
    domain: CourseHub.Courses,         # В каком домене живёт
    data_layer: AshPostgres.DataLayer  # Где храним данные

  # ==================== ХРАНЕНИЕ ====================
  postgres do
    table "lessons"
    repo CourseHub.Repo
  end

  # ==================== ПОЛЯ (Attributes) ====================
  attributes do
    uuid_primary_key :id

    attribute :title, :string do
      public? true               # видно в API и формах
      allow_nil? false
      constraints min_length: 3, max_length: 200
    end

    attribute :description, :string, public?: true
    attribute :content, :string, public?: true

    attribute :status, :atom do
      public? true
      default? :draft
      constraints one_of: [:draft, :published, :archived]
    end

    create_timestamp :inserted_at
    update_timestamp :updated_at
  end

  # ==================== СВЯЗИ (Relationships) ====================
  relationships do
    belongs_to :author, CourseHub.Accounts.User do
      public? true
      allow_nil? false
    end

    has_many :comments, CourseHub.Courses.Comment do
      public? true
    end

    many_to_many :tags, CourseHub.Courses.Tag do
      public? true
      through CourseHub.Courses.LessonTag
      source_attribute_on_join_resource :lesson_id
      destination_attribute_on_join_resource :tag_id
    end
  end

  # ==================== ДЕЙСТВИЯ (Actions) ====================
  actions do
    defaults [:create, :read, :update, :destroy]

    # Кастомное чтение
    read :published do
      filter expr(status == :published)
      pagination offset?: true, countable: true
      prepare build(sort: [inserted_at: :desc])
    end

    # Кастомное создание с логикой
    create :publish do
      argument :reason, :string
      change set_attribute(:status, :published)
    end

    # Полностью кастомное действие
    action :calculate_reading_time, :integer do
      argument :content, :string, allow_nil?: false
      run fn input, _context ->
        minutes = String.length(input.arguments.content) |> div(500) |> max(1)
        {:ok, minutes}
      end
    end
  end

  # ==================== ВЫЧИСЛЯЕМЫЕ ПОЛЯ ====================
  calculations do
    calculate :reading_time_minutes, :integer do
      calculation fn records, _context ->
        Enum.map(records, fn lesson ->
          (String.length(lesson.content || "") / 500) |> Float.ceil() |> trunc()
        end)
      end
    end
  end

  # ==================== ИНДЕКСЫ ====================
  identities do
    identity :unique_title_per_author, [:title, :author_id]
  end

  # ==================== АВТОРИЗАЦИЯ ====================
  policies do
    policy action_type(:read) do
      authorize_if always()
    end

    policy action(:update) do
      authorize_if expr(author_id == ^actor(:id))
    end
  end
end

ㅤ

Основные разделы Resource

Раздел	Что описывает	Аналог в обычном Elixir/Phoenix
`attributes`	Поля и их типы + валидация	Ecto Schema + поля
`relationships`	Связи с другими ресурсами	Ecto associations
`actions`	Все возможные операции (CRUD + кастомные)	Context-функции + Changesets
`calculations`	Вычисляемые поля (на лету)	Virtual fields / функции
`aggregates`	Агрегаты (count, sum, avg и т.д.)	Запросы с group_by
`identities`	Уникальные индексы	Ecto unique constraints
`policies`	Правила авторизации	Ручная проверка прав
`postgres`	Настройки хранения в PostgreSQL	Миграции

ㅤ

Ключевые особенности Resource

Всё в одном файле — огромный плюс для понимания сущности.
Introspection — Ash может в runtime читать всю информацию о ресурсе (поля, действия, политики). Это используется для генерации API, форм, админок.
Декларативность — ты описываешь что должно быть, а не как это реализовать.
Расширяемость — можно добавлять свои changes, preparations, validations, notifiers.
Embedded Resources — можно создавать ресурсы, которые хранятся не в отдельной таблице, а как JSON/Map внутри другого ресурса.

ㅤ

Когда создавать новый Resource?

Практически всегда, когда появляется новая бизнес-сущность (таблица или даже сложный JSON-объект).

ㅤ

🛠️ Подробнее об Actions (Действиях)

Action (Действие) — это явно объявленная операция, которую можно выполнить над ресурсом.

Всё взаимодействие с данными в Ash идёт только через Actions. Нельзя просто взять запись и изменить её вручную — всегда вызываешь действие.

Это заменяет:

Обычные функции в Context’ах Phoenix
Changesets в Ecto
Контроллеры и сервисные слои

ㅤ

Пять типов Actions

	Тип действия	Что делает?	В транзакции?	Что возвращает?
✨	`create`	Создаёт новую запись	Да	Новую запись ресурса
🔍	`read`	Читает одну запись или целый список	Нет (можно включить)	Запись или список записей
✏️	`update`	Обновляет существующую запись	Да	Обновлённую запись
🗑️	`destroy`	Удаляет запись	Да	Удалённую запись
⚡	`action` (Generic)	Любая кастомная бизнес-логика	Нет (можно включить)	Любое значение (что угодно)

ㅤ

Полный пример всех типов Actions

defmodule CourseHub.Courses.Lesson do
  use Ash.Resource, ...

  actions do
    # 1. Стандартные CRUD (defaults)
    defaults [:create, :read, :update, :destroy]

    # 2. Кастомное Read
    read :published do
      filter expr(status == :published)
      pagination offset?: true, countable: true, default_limit: 20
      prepare build(sort: [inserted_at: :desc], load: [:author, :comment_count])
    end

    read :for_user do
      argument :user_id, :uuid, allow_nil?: false
      filter expr(author_id == ^arg(:user_id))
    end

    # 3. Кастомное Create
    create :publish do
      argument :reason, :string, allow_nil?: true

      # Изменения (changes)
      change set_attribute(:status, :published)
      change set_attribute(:published_at, &DateTime.utc_now/0)
      change {CourseHub.Changes.NotifySubscribers, topic: "new_lessons"}

      # Хуки
      after_action fn _changeset, lesson, _context ->
        # side-effect после успешного создания
        {:ok, lesson}
      end
    end

    # 4. Кастомное Update
    update :archive do
      accept [:archive_reason]                    # какие поля можно менять
      change set_attribute(:status, :archived)
      change set_attribute(:archived_at, &DateTime.utc_now/0)
    end

    # 5. Generic Action (полностью кастомное)
    action :calculate_reading_time, :integer do
      argument :content, :string, allow_nil?: false
      argument :words_per_minute, :integer, default?: 200

      run fn input, _context ->
        minutes = String.length(input.arguments.content) 
                  |> div(input.arguments.words_per_minute) 
                  |> max(1)
        {:ok, minutes}
      end
    end
  end
end

ㅤ

Как вызывать Actions

# Через домен (рекомендуемый способ)
CourseHub.Courses.publish!(lesson, %{reason: "Готово"})

CourseHub.Courses.read!(CourseHub.Courses.Lesson, :published)

# Или с Ash.Query / Ash.Changeset для сложных случаев
query = Ash.Query.for_read(Lesson, :published)
Ash.read!(query)

ㅤ

Основные возможности Actions

1. `argument` — входные параметры

Позволяет передавать данные в действие и валидировать их.

argument :title, :string, allow_nil?: false, constraints: [min_length: 5]

argument :published_at, :datetime, default?: &DateTime.utc_now/0

argument :user_id, :uuid, allow_nil?: false

2. `accept` — какие атрибуты можно менять

Ограничивает список полей, которые разрешено изменять при create или update. Очень полезно для безопасности.

create :register do
  accept [:email, :password, :name]   # только эти поля можно передать
end

update :update_profile do
  accept [:name, :bio, :avatar_url]
end

3. `change` — трансформации данных

Самая мощная и часто используемая часть Actions. Здесь происходит основная бизнес-логика.

create :publish do
  argument :reason, :string

  # Встроенные изменения
  change set_attribute(:status, :published)
  change set_attribute(:published_at, &DateTime.utc_now/0)

  # Кастомный change-модуль
  change {CourseHub.Changes.NotifySubscribers, topic: "lessons"}

  # Анонимная функция
  change fn changeset, _context ->
    Ash.Changeset.change_attribute(changeset, :slug, generate_slug(changeset))
  end
end

4. `prepare` — подготовка запроса (в основном для `read`)

Позволяет заранее настроить запрос: сортировку, предзагрузку связей, дополнительные фильтры и т.д.

read :published do
  filter expr(status == :published)

  prepare build(
    sort: [inserted_at: :desc],
    load: [:author, :comments, :reading_time_minutes],
    limit: 20
  )
end

5. Хуки (before/after)

Позволяют выполнить код до или после выполнения действия.

create :publish do
  before_action fn changeset, _context ->
    # проверка перед выполнением
    validate_business_rules(changeset)
  end

  after_action fn _changeset, lesson, _context ->
    # side-effect после успешного создания
    LessonNotifier.publish_event(lesson)
    {:ok, lesson}
  end

  after_transaction fn 
    {:ok, lesson}, _context -> broadcast_new_lesson(lesson)
    {:error, _}, _ -> :ok 
  end
end

6. `transaction?` — управление транзакцией

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

action :transfer_money, :boolean do
  argument :from_account_id, :uuid
  argument :to_account_id, :uuid
  argument :amount, :decimal

  transaction? true   # будет выполнено в одной транзакции

  run fn input, _context ->
    # сложная операция с несколькими записями
    {:ok, true}
  end
end

7. `pipe_through` — переиспользование логики

Позволяет создавать общие пайплайны и подключать их к разным действиям (очень полезно для DRY).

# В Resource
pipelines do
  pipeline :ensure_admin do
    change ensure_actor_role(:admin)
    validate actor_role(:admin)
  end
end

create :create_admin_content do
  pipe_through :ensure_admin
  accept [:title, :content]
end

update :update_admin_content do
  pipe_through :ensure_admin
  accept [:title, :content]
end

ㅤ

Почему Actions — это круто?

Полная типизация и introspection — Ash знает всё о действии в runtime (используется для GraphQL, форм, админок)
Декларативность — код читается как документация бизнеса
Повторное использование — одно действие можно использовать в LiveView, API, Background Job, Tests
Безопасность — политики авторизации привязываются к конкретным действиям
Тестируемость — легко тестировать отдельные действия

ㅤ

Сравнение с классическим Elixir/Phoenix

Подход	Где логика?	Кол-во файлов	Понятность
Ecto + Context	Context + Changeset	4–8	Средняя
Ash Actions	В одном Resource	1	Высокая

Actions — это то место, где живёт вся бизнес-логика твоего ресурса

ㅤ

🏢 Что такое Domain (Домены)?

Domain (Домен) — это логический контейнер, который объединяет группу связанных Resources (ресурсов).

Он похож на Phoenix Context, но гораздо мощнее. Если Resource — это описание одной сущности (как User, Lesson, Order), то Domain — это «модуль» или «bounded context» (в терминах DDD), который собирает вместе несколько сущностей одной бизнес-области.

Пример:

Accounts — домен для пользователей, профилей, авторизации
Courses — домен для курсов, уроков, тестов, enrollments
Billing — домен для платежей, подписок, инвойсов
Therapy — домен для терапии, разговоров, сообщений (из реальных примеров)

ㅤ

Три главные цели Domain

Группировка ресурсов

Организация проекта. Вместо того чтобы все ресурсы были разбросаны, они явно лежат в логических группах.
Централизованный Code Interface

Domain позволяет определять удобные функции-обёртки для вызова действий ресурсов.
Общие настройки и cross-cutting concerns

Здесь можно задать поведение, которое применяется ко всем ресурсам домена (таймауты, пагинация по умолчанию, авторизация и т.д.).

ㅤ

Как выглядит Domain на практике

defmodule CourseHub.Courses do
  use Ash.Domain, otp_app: :course_hub

  # 1. Группировка ресурсов
  resources do
    resource CourseHub.Courses.Course
    resource CourseHub.Courses.Lesson
    resource CourseHub.Courses.Quiz
    resource CourseHub.Courses.Enrollment
  end

  # 2. Code Interface — удобные функции
  define :get_lesson, action: :read, args: [:id], get?: true
  define :list_published_courses, action: :published
  define :enroll_user, action: :create, resource: CourseHub.Courses.Enrollment

  # 3. Общие настройки
  execution do
    timeout :timer.seconds(30)        # глобальный таймаут
    default_page_size 20
  end

  # Включение AshAdmin (админка)
  admin do
    show? true
  end
end

ㅤ

Зачем нужен Domain?

Организация и границы. Чётко разделяет разные части приложения (как bounded contexts в DDD). Accounts не знает про Billing без явного отношения
Удобный публичный API. Вместо Ash.read!(CourseHub.Courses.Lesson, ...) ты пишешь красиво:

  CourseHub.Courses.get_lesson!(lesson_id)
  CourseHub.Courses.list_published_courses!()

Централизованное управление. Можно отключить авторизацию для всего домена в dev-режиме, задать общие политики, notifiers и т.д.
Introspection и расширения. Многие расширения Ash (GraphQL, JsonApi, Phoenix и т.д.) работают на уровне домена
Тестирование и изоляция. Легче тестировать одну бизнес-область целиком

ㅤ

Лучшие практики при работе с доменом

Один ресурс — один домен. Ресурс не может принадлежать нескольким доменам одновременно.
Сколько доменов делать?
- Маленький проект → 1–3 домена.
- Средний/большой → по одному на крупную бизнес-область (Accounts, Core, Billing, Notifications и т.д.). Это помогает в масштабировании и понимании архитектуры.
Code Interface — очень мощная фича. Ты можешь определять не только простые обёртки, но и с предустановленными фильтрами, load'ами и т.д.

ㅤ

Сравнение: Domain vs Resource

Аспект	Resource	Domain
Что описывает	Одну сущность	Группу сущностей
Где лежит логика	Атрибуты, действия, политики	Группировка + общие настройки
Вызов кода	Через домен	Публичный интерфейс приложения
Аналог в Phoenix	Schema + Context (частично)	Phoenix Context
Количество на проект	Много (по одной на таблицу)	Мало (по бизнес-областям)

ㅤ

Почему Domain особенно полезен?

Проект растёт > 10–15 ресурсов
Нужна сложная авторизация (policies)
Делаешь GraphQL / JSON:API / Admin-панель
Командная разработка — всем нужно понимать границы

ㅤ

⚔️ Ash + Phoenix vs Ecto + Phoenix

Аспект	Phoenix + Ecto (классика) 😐	Phoenix + Ash 🔥	Кто выигрывает?
Организация бизнес-логики	Разбросана по Context, Changeset, отдельным модулям	Всё в одном Resource — атрибуты, действия, политики, связи	Ash (всё на виду)
CRUD-операции	Пишешь вручную: create, read, update, delete + boilerplate	`defaults [:create, :read, :update, :destroy]` — и готово ✨	Ash (1 строка)
Авторизация	Ручные проверки / Bodyguard / scopes	Декларативные Policies (secure by default) ⚡	Ash (автоматика)
Вычисляемые поля	Virtual fields + функции в Context	Calculations — автоматически подгружаются и кэшируются	Ash
Количество файлов на сущность	3–6+ файлов (Schema + Context + Changeset + Policy)	1 файл — Resource	Ash
Генерация API	Absinthe / GraphQL вручную + много кода	`AshGraphql` или `AshJsonApi` — добавил расширение и готово	Ash
LiveView формы	Phoenix.Component + ручная валидация	AshPhoenix.Form — формы сами знают всё	Ash
Multi-tenancy	Пишешь сам (или используешь схемы)	Встроено в Policies (attribute-based или context-based)	Ash
Поддерживаемость через 2–3 года	Средняя (логика расползается)	Высокая (всё декларативно и в одном месте)	Ash
Скорость разработки	Нормальная на старте	Значительно быстрее после кривой обучения 🚀	Ash (после обучения)
Гибкость	Максимальная (полный контроль)	Очень высокая + можно escape в чистый Ecto когда нужно	Ничья
Кривая обучения	Легче для новичков	Круче, но окупается в большом проекте	Ecto

Что стоит выбрать в 2026 году?

Плюсы Ash 🔥

Декларативность → «Опиши домен — остальное Ash выведет сам»
Сокращение шаблонного кода (часто встречаются отзывы о Ash вроде: «я создаю программы, используя в 3–5 раз меньше строк»)
Автоматическая генерация GraphQL, JSON:API, Admin-панели, аутентификации
Политики авторизации и multi-tenancy из коробки
Отличная поддерживаемость на длинной дистанции (именно то, о чём мечтают в продакшене)

Плюсы классического Phoenix + Ecto 😐

Полный контроль над каждым байтом кода
Проще для совсем маленьких проектов и пет-проектов
Нет дополнительной абстракции (если ты любишь «голый» Elixir)
Легче для новичков в Elixir

Когда выбирать что?

Маленький пет-проект или эксперимент → бери чистый Phoenix + Ecto
Средний/крупный проект, SaaS, долгоживущее приложение → Phoenix + Ash (экономия времени и нервов огромная)
Хочешь и то, и другое → можно спокойно миксовать в одном проекте (Ash и обычный Ecto отлично уживаются)

ㅤ

😴 В заключение

Ash — это не просто библиотека, а изменение подхода к разработке на Elixir. Он особенно хорошо заходит в проектах среднего и крупного размера, где важны чистота архитектуры, скорость разработки и долгосрочная поддерживаемость.

Конечно, у него есть кривая обучения, и в совсем простых пет-проектах он может быть избыточен. Но если вы устали от расползающейся логики и хотите чёткой, декларативной структуры — Ash дарит очень приятное ощущение контроля над кодом.

ㅤ

🥴 От автора

Спасибо большое за интерес к этой статье! Надеюсь, она помогла разобраться, что представляет собой Ash и зачем он используется.

Если эта статья пришлась вам по душе и хочется ещё материалов такого плана, присоединяйтесь ко мне в моём телеграм-канале, где выкладываю обзоры книг, публикации по Elixir, переводы технической литературы и интересные новости!

[Boost]

Artyom Molchanov — Thu, 19 Mar 2026 17:05:36 +0000

Alexey Bolshakov

Mar 19

AD9833 DDS Generator Board

#dds #microchips #stm8 #microcontroller

Comments

5 min read

[Boost]

Artyom Molchanov — Sun, 15 Mar 2026 13:11:26 +0000

Sagiv ben giat

Mar 12

The Internet Is Getting Quieter - Who Will Feed the Next Generation of AI?

#ai #knowledgesharing #stackoverflow #opinion

Comments 30

5 min read

BEAM: In Plain English

Artyom Molchanov — Thu, 25 Sep 2025 07:00:03 +0000

Imagine a universe where billions of messages, calls, and financial transactions happen every second. Each message reaches its recipient flawlessly, phone calls remain uninterrupted, and funds are transferred instantly. What ensures such impeccable performance? No, it's not magic—it's virtual machines—the unsung heroes of digital infrastructure.

Among them stands out one remarkable machine — BEAM. Created decades ago, it looks like an invention from a distant future. It powers stable operations for giants like WhatsApp, Discord, financial services, and IoT systems. Even after all these years since its inception, BEAM continues to impress with its performance and reliability.

This article is not intended as an in-depth exploration into the inner workings of BEAM or its implementation details. We won't delve into byte code flow or provide specific internal code snippets here. Instead, this piece aims to give you a general understanding of what BEAM does, why it's important, and how it can benefit your business under heavy loads. For those who want to dive deeper into BEAM’s internals, I recommend reading the book — The BEAM Book: Understanding the Erlang Runtime System.

In today's era characterized by rapid development of real-time technologies, artificial intelligence, and mass parallel user connections, BEAM excels at providing high response speed, reliability even during failures, and quick adaptation to increasing load, making it an optimal solution for complex challenges. But let's start with the basics!

What Is a Virtual Machine? 🤔

Imagine writing a program that needs to run everywhere—on laptops, smartphones, servers, smart speakers, etc. How do you ensure compatibility across different operating systems and hardware configurations? The answer lies in using a virtual machine (VM). It's a special execution environment that interprets your code, acting as a bridge between your application and the underlying device. The VM takes intermediate code (like Java bytecode) and translates it into instructions suitable for each platform, freeing you from worrying about memory management or multithreading intricacies. In essence, a virtual machine serves as a universal adapter enabling your code to run anywhere!

Additionally, many virtual machines come equipped with useful tools such as automatic garbage collection, built-in performance optimizations, and data protection mechanisms. These features make app development significantly easier and more efficient. Without VMs, creating modern projects ranging from mobile games to large-scale cloud services would be much harder.

Why Are Virtual Machines Needed? 🌟

Virtual machines aren't just developer conveniences but powerful tools for building versatile, reliable, and scalable solutions. Let's explore their key advantages through practical examples:

Cross-platform Compatibility 📱💻

Write once, run anywhere. An example is a banking app written in Java running seamlessly both on bank servers and client Android phones thanks to JVM. This saves time and resources, especially valuable in enterprise-level development involving diverse platforms.
Resource Management 🧹

Virtual machines handle resource allocation, including memory control (via garbage collection), threading, and hardware interaction. For instance, in the Erlang VM (BEAM), each process gets isolated memory areas, preventing issues caused by individual process crashes. Such architecture minimizes bugs and simplifies coding tasks, relieving developers from manually managing memory allocation and deallocation.
Security 🔒

By isolating executable code from the OS, virtual machines create secure sandboxes protecting against potential threats posed by harmful programs. This feature is crucial in environments like AWS Lambda or Google Cloud Functions, where thousands of code fragments from various users execute simultaneously on shared hardware.
Optimization ⚡

Many VMs dynamically optimize code execution while applications are running. One prominent example is Just-In-Time compilation (JIT), which makes browser engines like V8 incredibly fast. Starting with version OTP 24, BEAM introduced its own JIT mechanism, further enhancing performance. These techniques prove invaluable when dealing with repetitive computations common in highly loaded web apps.
Support for Complex Systems 🌐

Some VMs are specifically designed to support concurrency, distributed computing, and fault tolerance. For example, popular game server infrastructures, like those powering League of Legends, rely heavily on BEAM, efficiently handling millions of concurrent player connections with minimal latency and high reliability.

Thus, virtual machines allow developers to focus directly on product functionality rather than low-level technicalities, accelerating development processes and reducing costs.

Popular Virtual Machines: Who's Who? 🦸‍♂️

JVM (Java Virtual Machine): Used for Java, Kotlin, Scala. Ideal for large business systems (banking solutions), web servers (Spring Framework), and Android platforms.

Pros: Extensive ecosystem (huge library availability), Just-In-Time compilation technology.
Cons: High initial RAM usage, comparatively slow startup times.
Fact: Adopted by nearly 90% of Fortune 500 companies worldwide.

V8 (JavaScript Engine): Powering Node.js and modern browsers. Optimized for web environments.

Pros: Exceptional performance for client-side websites.
Con: Not well suited for long-term server-based solutions, where BEAM shines.

CLR (.NET Common Language Runtime): Supports languages within the .NET family, notably C#. Strongly integrated with Microsoft technologies (Azure).

Pros: Seamless integration with Windows platforms.
Con: Limited cross-platform capabilities compared to JVM.

BEAM (Erlang VM): Designed for Erlang, Elixir, and other compatible languages (LFE, Alpaca). Best suited for highly scalable, resilient, and concurrent systems, excelling in messaging, telecommunications, and fintech.

Pros: Capable of handling millions of simultaneous processes with minimal delays.
Con: Smaller toolkit and framework libraries, though actively growing (Phoenix, Nerves frameworks).

Comparison Table:

VM	Strengths	Weaknesses	Use Cases
JVM	Versatility, extensive ecosystem	Memory consumption, startup lag	Enterprise, Android
V8	Speed for web clients	Unsuitable for backend servers	Node.js, Browsers
CLR	Integration with Microsoft tech	Dependence on MS ecosystem	.NET, Azure
BEAM	Concurrency, resilience	Fewer libraries & frameworks	Real-time, Telecom

By 2025, with the rise of IoT and streaming data, BEAM has become particularly relevant for real-time applications.

Deeper Look Into BEAM 🌌

BEAM is a virtual machine engineered for programming languages like Erlang, Elixir, and others (such as LFE). Initially developed in the 1990s by Ericsson for telecommunication purposes, where reliability and capacity to manage massive traffic were critical, today BEAM forms the backbone of numerous high-performance services. It handles billions of daily messages (as seen in WhatsApp), supports millions of online gamers simultaneously (products like League of Legends), and keeps real-time chat services (Discord) functioning smoothly. As the need for high throughput, low latency, and robustness grows, BEAM proves indispensable in 2025 more than ever before.

History of BEAM: From Telco to Global Platforms 📜

Originally, BEAM stood for "Bogdan's Erlang Abstract Machine" named after Bogumil Hausman ("Bogdan"), who created its first iteration. However, over time, it became associated with another author—"Björn's Erlang Abstract Machine", reflecting contributions made by Björn Gustavsson, who maintains the current implementation. Both contributors played significant roles in shaping the system while working at Ericsson.

Before BEAM emerged, there was another virtual machine called JAM (Joe's Abstract Machine)—the first interpreter for the Erlang language. Developed by Joe Armstrong alongside Mike Williams in C, detailed insights are found in the developers' blog.

Therefore Bogumil (“Bogdan”) Hausman created TEAM (Turbo Erlang Abstract Machine). It compiled the Erlang code to C code, which was then compiled to native code using GCC.

Today, BEAM finds widespread use in finance (Klarna), advertising (AdRoll), notification systems (Pinterest), and Internet of Things (IoT) deployments (Nerves). With advancements such as Just-In-Time compiler introduction in OTP 24 and type improvement enhancements in Elixir v1.15+, BEAM remains a viable choice. Future plans include closer alignment with WebAssembly for supporting web applications.

What's So Great About BEAM? 🚀

BEAM distinguishes itself among other virtual machines due to unique characteristics essential for scalable and demanding applications. Below are its main advantages, supported by concrete figures and comparisons with similar solutions:

Fast and Lightweight Processes ⚡

Process creation in BEAM takes only microseconds, consuming approximately 2.5 KB per process, allowing millions of instances to coexist on a single machine. Compared to Java threads requiring megabytes of memory, BEAM offers superior efficiency.

🧠 While asynchronous tasks in Rust are lightweight too, BEAM surpasses in building distributed solutions due to its actor model, isolated processes with negligible overhead, auto-failure recovery via supervisors, and hot code swapping without downtime.
Actor Model 🎭

Processes behave independently, exchanging messages without sharing resources or causing blocking. Unlike Java threads, this greatly simplifies concurrent processing. Imagine a chat messenger like Discord where each room acts as an independent process freely accepting new messages regardless of other activities. Performance is impressive: BEAM can process roughly 100k messages per second on a single core.
Let It Crash Philosophy 💥

BEAM embraces the principle of “let it crash”: if a process fails, it simply stops executing. Yet, thanks to careful design, failure goes largely unnoticed by end-users. Consider managing a busy restaurant where someone suddenly leaves mid-shift. Typically, chaos ensues, disrupting service. In BEAM, however, there's a supervisor-like manager immediately spawning a replacement process. Customers continue receiving orders promptly, unaware of any interruption.

☎️ This philosophy proved effective back in the '90s when Ericsson used BEAM to maintain large telecommunication stations. If a component crashed, the overall system remained operational without disruption.
Hot Code Reloading 🔄

Applications can update themselves without halting ongoing operations. BEAM holds two versions of software modules simultaneously, switching almost instantaneously. In contrast, Java transitions require additional effort and may cause temporary delays. Successful implementations include payment gateway Klarna, updating continuously without a single second of downtime, ensuring continuous shopping experiences for customers.
Distributed Systems 🌐

Individual nodes connect into unified clusters through network links. This setup enhances fault tolerance and horizontal scaling. Take Pinterest notifications: thousands of new servers easily join existing clusters, boosting total output without compromising individual node performance. Scalability extends to tens of thousands of nodes with minimal request latencies.
Low Latency ⏱

Incremental garbage collection minimizes delays. The Phoenix framework, built atop BEAM, handles thousands of requests with millisecond-level responses. Other languages like Python occasionally experience longer pauses due to their garbage collection models, whereas BEAM consistently performs under heavy loads with low latency.
Just-In-Time Compilation 🚀

Starting with OTP 24, BEAM introduces Just-In-Time compilation, improving computational-intensive task speeds by up to 20–30%. Although BEAM primarily focuses on concurrency, this optimization dramatically increases execution speed for computation-heavy tasks. Parsing JSON files now happens faster thanks to enhanced compiler optimizations.

Inside BEAM: How Does It Work? 🛠

1. Scheduler: Maestro of Multitasking 🎻

The scheduler in BEAM operates like a conductor leading an orchestra. Thousands of musicians (processes) play together, each needing their turn to perform. Nobody plays for too long—otherwise, music turns chaotic.

📖 Real-world Example: A single WhatsApp server handled millions of active connections simultaneously. Implementing this feat using conventional OS threads would have been impossible, yet BEAM manages it gracefully with its unique scheduling scheme.

How It Works:

There is one scheduler per CPU core. On an eight-core server, eight schedulers operate.
Every process receives a fixed number of steps ("reductions") before yielding control to another process.
Processes fall into two queues: ready-for-execution and waiting-for-resources.
Load balancing employs task stealing mechanics to redistribute workload evenly.
Time-wheel structure stores active timers for efficient timing operations.

📌 Common Issue: Long-running Built-In Functions (BIFs) executed without yielding control can block scheduler activity.

2. Garbage Collection: Keeping Memory Clean 🧹

The garbage collector (GC) in BEAM works similarly to a diligent janitor silently cleaning tables in a bustling city full of restaurants. Each process has its dedicated storage area ("heap"). When unused objects fill a heap, cleanup occurs locally, leaving other processes unaffected.

BEAM implements generational garbage collection: newer elements ("young generation") frequently cleaned because they tend to die quickly, while older generations are checked less often.

📌 Common Issue: Accumulation of long-lived objects can lead to increased resource consumption. Monitor parameters like high_water carefully.

Large binary data (files, images) resides separately outside the GC zone, avoiding unnecessary bloat.

📖 Real-world Example: Discord manages millions of active channels on BEAM. Even if one particular chat accumulates transient data, the cleanup mechanism swiftly removes it without impacting other chats’ performance.

Algorithm Overview:

Heap and stack expand towards each other until meeting, triggering cleanup.
Two types of cycles exist: minor (frequent young-generation cleanups) and major (infrequent old-generation cleanups).
Data copying technique moves values between two memory zones ("from space" → "to space").

✨ Carefully monitor memory growth dynamics in your processes. Rapidly expanding sizes might indicate presence of long-living objects requiring architectural adjustments.

3. Register-Based Architecture: Faster and More Efficient 🧠

BEAM utilizes register-based architecture. Registers act as small, fast-access memory regions storing intermediate results of calculations. Each register holds specific values participating in computational operations. By keeping data close to the processor, registers enable swift access and high-performance operation.

Example: Simple addition (add(A, B) resulting value stored in registers X0 and X1).

Operational Principles:

Registers X (up to 1024): Store function arguments.
Registers Y: Local variables.
Instructions like move and call, direct memory addressing allowed. JIT compilation substantially improves performance.

📌 Common Issue: Overflowing registers — pay attention to function size and optimization strategies.

✨ Performance Tips: Minimize stack usage, utilize registers effectively for intermediate result storage.

4. Supervisors and Fault-Tolerance: Let It Crash! 💥

In typical systems, a failing process means disaster. In BEAM, however, this event aligns with the development philosophy.

Consider electrical networks: A vast grid where one substation breaks down. Normally, entire neighborhoods lose power. In BEAM, automated switches disconnect the faulty element and reconnect reserve units instantly, preserving normalcy throughout the city.

Supervisors form hierarchical structures. When child processes crash, parent supervisors decide whether to restart affected components individually or collectively.

Such architecture guarantees automatic restoration of system integrity.

Mechanisms involved: tree-structured supervision, one-for-one strategy, state monitoring (running, garbage collection).

📌 Common Issue: Ignoring supervisor role, opting for custom solutions instead of proven OTP libraries.

✨ Developer Advice: Design applications tolerant of errors, leave failure-handling logic to specialized supervisor mechanisms.

5. Dynamic Code Loading and Distributed Systems 🌍

BEAM allows live updates to running applications. Similar to a musician changing instruments mid-performance invisibly to listeners.

Two module versions reside simultaneously: Old handles ongoing requests, new accepts fresh ones. Updates occur transparently without stopping the application.
Code Replacement: Achieved via command :code.load_file(Module). Follow proper update rules to avoid disruptions.
Distribution: Check remote node availability using net_adm:ping(Node), leverage Mnesia database. Clustering examples exist in Kubernetes environments utilizing BEAM-powered virtual machines.
Scaling: Utilize OTP tools for cluster-wide node monitoring.

6. Scalability: BEAM Network Across Thousands of Nodes 🌐

BEAM isn't merely a standalone node but a connected network behaving as a unified whole. Individual network members interact seamlessly, forming a coherent distributed infrastructure.

Key benefits of this approach:

Deploy clusters spanning multiple servers, enabling transparent communication between processes.
Particularly beneficial in IoT systems and microservices architectures, where message delivery automatically distributes across appropriate servers.

📖 Real-world Case Study: Pinterest applied this technology to deliver notifications. As traffic grew, adding extra servers scaled the system effortlessly.

BEAM in 2025: Why Should You Pay Attention? 🚀

Handling Massive Traffic: WhatsApp manages millions of simultaneous connections.
Scalable Microservices: Effortless deployment and management in Kubernetes.
Real-time Operations: Phoenix provides lightning-fast chat communications.
Reliability and Resilience: Proven in big players like Klarna.
IoT and AI: Nerves for IoT devices, TensorFlow compatibility via port mechanisms.
Future Development: Enhanced performance through JIT compilation, WebAssembly support for web apps.

📖 Success Story: Pinterest reduced notification delay by 50%, leveraging BEAM.

BEAM — The Future That's Already Here! 🌌

As we stand in 2025, Elixir and Erlang occupy niche positions among commonly used development tools, drawing little public attention. Personally, I believe this situation is unfair given the truly amazing and innovative possibilities offered by these technologies. Despite the learning curve and project complexity, the rewards promise to be substantial!

Embrace the world of Elixir/Erlang, launch a new project, and experience the true power of the BEAM virtual machine! ✨

Final Note from the Author

Thank you very much for taking interest in this article! Hopefully, it helped clarify what BEAM is and why it's so widely adopted. Initially, I planned to write something more advanced and filled with technical details, but realized I'd struggle to top the comprehensive guide provided in the book The BEAM Book: Understanding the Erlang Runtime System. Thus, I've opted for a simpler explanation.

BEAM: Простыми словами

Artyom Molchanov — Thu, 25 Sep 2025 06:58:34 +0000

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

Среди них есть одна выдающаяся машина — BEAM. Созданная еще в прошлом веке, она выглядит как разработка из далекого будущего. Именно она поддерживает стабильную работу таких гигантов, как WhatsApp, Discord, финансовые сервисы и IoT системы. Даже спустя десятилетия после своего появления, BEAM продолжает поражать своей производительностью и надежностью.

Цель этой статьи вовсе не в подробном погружении в механизмы работы BEAM и внутренние детали реализации. Здесь мы не будем разбираться, куда уходят байты или приводить конкретные внутренние фрагменты кода. Эта статья предназначена лишь для общего понимания сути технологии, её назначения и возможностей, полезных для вас и вашего бизнеса в условиях больших нагрузок. Для тех, кто желает глубже изучить внутреннее устройство BEAM, рекомендую книгу — The BEAM Book: Understanding the Erlang Runtime System на английском языке. (А вот русскоязычная версия вскоре появится в моём телеграм-канале)

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

Что такое виртуальная машина? 🤔

Представь себе написание программы, которую ты хочешь запустить абсолютно на всём — будь то ноутбук, смартфон, сервер или даже умная колонка. Как добиться совместимости с разными операционными системами и железом? Решение простое — использовать виртуальную машину (ВМ). Она представляет собой специальную среду выполнения, которая интерпретирует твой код, действуя как мостик между твоим приложением и конкретным устройством. ВМ берет промежуточный код (например, байт-код Java) и преобразует его в инструкции, подходящие именно этой платформе, освобождая тебя от забот о деталях работы памяти или многопоточности. Проще говоря, виртуальная машина — это своего рода универсальный переходник, позволяющий твоему коду запускаться повсеместно!

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

Зачем нужны виртуальные машины? 🌟

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

Кроссплатформенность 📱💻

Написал код один раз — работает везде. Например, банковское приложение на Java запускается на сервере банка и на Android-смартфоне клиента благодаря JVM. Это экономит время и ресурсы, особенно в enterprise-разработке, где команды работают с разными платформами.
Управление ресурсами 🧹

Виртуальная машина берет на себя контроль над оперативной памятью (например, посредством сборки мусора), многопоточностью и взаимодействием с техникой. Так, в VM Erlang (BEAM) каждому процессу выделяется отдельная область памяти, что позволяет избежать проблем с утечками даже при падении отдельных процессов. Такая архитектура снижает риск возникновения багов и существенно облегчает написание кода, поскольку разработчикам больше не приходится самостоятельно заботиться о выделении и освобождении памяти.
Безопасность 🔒

За счет изоляции исполняемого кода от операционной системы, виртуальные машины создают своего рода песочницу, защищающую систему от потенциально опасных действий программы. Эта функция незаменима в облаках вроде AWS Lambda или Google Cloud Functions, где на одной машине одновременно выполняются тысячи фрагментов кода от разных пользователей.
Оптимизация ⚡

Многие виртуальные машины способны динамически оптимизировать исполнение программного кода прямо во время работы приложения. Яркий пример — механизм Just-in-time компиляции (JIT). Именно благодаря ему браузерные движки типа V8 делают JavaScript невероятно быстрым, а среда BEAM начиная с версии OTP 24 заметно повышает производительность при помощи собственного механизма JIT. Такие технологии полезны там, где программа многократно повторяется, как, например, в высоконагруженных веб-приложениях.
Поддержка сложных систем 🌐

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

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

Популярные виртуальные машины: Кто есть? 🦸‍♂️

JVM (Java Virtual Machine): Используется для Java, Kotlin, Scala. Отлично подходит для крупных бизнес-систем (например, банковские решения), веб-серверов (Spring Framework) и платформ Android.

Преимущества: обширная инфраструктура (огромное количество готовых библиотек), технология Just-In-Time компиляции.
Недостатки: большие начальные затраты оперативной памяти и сравнительно долгий запуск приложений.
Факт: Решение применяется в большинстве (около 90%) крупнейших мировых корпораций (Fortune 500).

V8 (JavaScript Engine): Основана в Node.js и современных браузерах. Оптимизировано для работы в веб-пространстве.

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

CLR (.NET Common Language Runtime): Поддерживает языки семейства .NET, включая C#. Хорошо интегрируется с технологиями от Microsoft (например Azure).

Преимущества: тесная совместимость с Windows-платформой.
Недостаток: ограниченная кросс-платформенность по сравнению с JVM.

BEAM (Erlang VM): Работает с языками Erlang, Elixir, LFE. Лучше всего справляется с высоко нагруженными системами, ориентированными на масштабируемость, устойчивость и параллельность обработки запросов. Прекрасно подходит для мессенджеров, телекоммуникационных сервисов и финансовых технологий.

Преимущества: поддерживает миллионы параллельных процессов одновременно, минимизирует задержки выполнения операций.
Недостаток: меньший объем библиотеки инструментов и фреймворков, хотя активно развивается (например Phoenix, Nerves).

Сравнение в таблице:

ВМ	Сильные стороны	Слабые стороны	Применение
JVM	Универсальность, экосистема	Память, запуск	Enterprise, Android
V8	Скорость для веб	Не для серверов	Node.js, браузеры
CLR	Интеграция с Microsoft	Привязка к экосистеме	.NET, Azure
BEAM	Конкурентность, отказоустойчивость	Экосистема, численные расчёты	Реальное время, телеком

В 2025 году, с ростом IoT и стриминга данных, BEAM особенно актуальна для реального времени.

Подробнее о BEAM 🌌

BEAM представляет собой виртуальную машину, предназначенную для работы с языками программирования Erlang, Elixir и рядом других (например, LFE, Alpaca). Изначально она была создана в 1990-е годы в компании Ericsson специально для телекоммуникаций, где крайне важны устойчивость к сбоям и способность выдерживать огромные нагрузки. Сейчас BEAM лежит в основе многих высоконагруженных сервисов: она обслуживает миллиарды сообщений ежедневно (как WhatsApp), поддерживает миллионы пользователей онлайн-игр одновременно (например, продукты Riot Games) и обеспечивает бесперебойную работу чат-сервисов реального времени (таких как Discord). В условиях современного мира, где критически важными становятся высокая производительность, минимальное время отклика и надежность, в 2025 году BEAM демонстрирует свою незаменимость сильнее, чем когда бы то ни было ранее.

История BEAM: От телекома к глобальным платформам 📜

Изначально аббревиатура BEAM расшифровывалась как «Bogdan’s Erlang Abstract Machine» в честь Богумила "Богдана" Хаусмана, который создал первую её версию. Однако сейчас название часто связывают с именем другого автора — «Björn’s Erlang Abstract Machine», поскольку именно Бьёрн Густавссон разработал и поддерживает актуальную реализацию. Оба специалиста внесли значительный вклад в развитие системы, трудясь в компании Ericsson.

До появления BEAM существовала другая виртуальная машина — JAM (Joe’s Abstract Machine), ставшая первым интерпретатором языка программирования Erlang. Она была создана Джо Армстронгом совместно с Майком Уильямсом на языке C (подробности можно найти в блоге разработчиков).

Поэтому Богумил («Богдан») Хаусман создал TEAM (Турбо-Эрланг-Абстрактную-машину). Она компилировала код Эрланга в Си-код, который затем компилировался в нативный код с помощью GCC.

На сегодняшний день BEAM активно применяется в финансовом секторе (например, Klarna), рекламной индустрии (AdRoll), системах уведомлений (Pinterest) и сфере Интернета вещей (Nerves). Благодаря внедрению технологии Just-In-Time компилятора в версии OTP 24 и развитию языка Elixir до уровня 1.15+, включающего улучшение работы с типизацией, BEAM продолжает оставаться актуальным решением. В будущем планируется ещё большее сближение с технологией WebAssembly для поддержки веб-приложений.

Почему BEAM — это круто? 🚀

BEAM отличается от прочих виртуальных машин своими уникальными характеристиками, особенно полезными для масштабируемых и нагруженных приложений. Рассмотрим основные преимущества вместе с конкретными примерами, цифрами и сравнением с аналогичными решениями:

Быстрые и лёгкие процессы ⚡
Создание процессов в BEAM занимает всего несколько микросекунд, занимая около ~2.5 КБ оперативной памяти каждый процесс, что позволяет одновременно запустить миллионы экземпляров на одной машине. В отличие от потоков Java Virtual Machine, потребляющих целые мегабайты памяти.

🧠 Асинхронные задачи в Rust также легковесны, однако BEAM значительно удобнее для построения распределённых решений благодаря встроенной модели акторов, изолированные процессы с минимальными накладными расходами, автоматическую отказоустойчивость через супервизоры и горячую замену кода без остановки системы.
Модель акторов 🎭
Процессы здесь ведут себя как самостоятельные акторы, обменивающиеся сообщениями друг с другом без общих ресурсов и блокировки. Это значительно упрощает работу по сравнению с потоками Java Virtual Machine. Например, представим себе мессенджер вроде Discord, где каждая отдельная комната чата функционирует как независимый процесс, свободно принимающий новые сообщения независимо от других процессов. Производительность впечатляет: виртуальная машина BEAM способна обработать около ста тысяч сообщений всего за одну секунду на одном ядре.
Философия «пусть падает» 💥
BEAM основывается на принципе «let it crash»: когда какой-либо процесс ломается, он просто прекращает свою работу. Однако, благодаря продуманному подходу, такое событие практически незаметно для пользователей. Допустим, вы управляете большим рестораном, и вдруг кто-то из сотрудников уходит посреди смены. Обычно такая ситуация привела бы к хаосу среди клиентов, но в BEAM действует своего рода супервайзер («менеджер»), который моментально запускает замену сбойного процесса новым экземпляром. И клиент продолжает получать заказ вовремя, даже не заметив заминки.

☎️ История показывает, насколько эффективна эта философия: ещё в девяностые годы прошлого века компания Ericsson использовала BEAM для поддержания работоспособности крупных телекоммуникационных станций. Если один из компонентов падал, система продолжала функционировать бесперебойно.
Горячая замена кода 🔄
Система позволяет обновлять программы, не останавливая работающую систему. BEAM держит одновременно две версии программного модуля, переключаясь между ними почти мгновенно. Для сравнения, в Java такой переход требует больше усилий и зачастую вызывает кратковременные задержки.

📖 Пример из практики: Торговая площадка Klarna, которая обновляется без единой секунды простоя, позволяя клиентам совершать покупки непрерывно.
Распределённые системы 🌐
Отдельные узлы BEAM соединяются в единую распределённую систему через сетевые соединения. Такой подход обеспечивает высокую отказоустойчивость и лёгкость горизонтального масштабирования.

📖 Пример из практики: в Pinterest тысячи новых серверов легко подключаются к существующему кластеру, увеличивая общую производительность без потери производительности отдельных частей. Масштабируемость достигает десятков тысяч узлов с минимальной задержкой обработки запросов.
Низкая задержка ⏱
За счёт инкрементальной сборки мусора BEAM сводит задержки к минимуму. Фреймворк Phoenix, построенный поверх BEAM, способен обрабатывать тысячи запросов с минимальным временем отклика, измеряемым в миллисекундах. Другие языки программирования, такие как Python, иногда испытывают длительные паузы из-за своей модели сбора мусора, тогда как BEAM уверенно справляется с большими нагрузками, сохраняя низкую задержку.
JIT-компиляция 🚀
Начиная с версии OTP 24, BEAM поддерживает технологию Just-In-Time компиляции, ускоряя выполнение интенсивных вычислительных операций примерно на 20–30%. Хотя основной фокус BEAM всё равно остаётся на параллельной обработке, новая оптимизация существенно повышает скорость выполнения ресурсоёмких задач. Например, парсинг JSON-файлов теперь выполняется заметно быстрее благодаря улучшенной оптимизации компилятором.

Внутренности BEAM: Как это работает? 🛠

1. Планировщик: Дирижёр многозадачности 🎻

Планировщик BEAM — это как дирижёр в оркестре. У него тысячи музыкантов (процессов), и каждому нужно время, чтобы сыграть свою партию. Никто не играет слишком долго — иначе музыка превратится в хаос.

📖 Пример из практики: Один сервер WhatsApp с использованием BEAM одновременно обслуживал миллионы подключений. Такое было бы невозможно реализовать через обычные потоки операционной системы, однако BEAM справляется с этой задачей благодаря своей уникальной схеме планирования процессов.

Механизм работы:

Количество планировщиков соответствует числу ядер процессора. Например, на восьмиядерном сервере действует восемь планировщиков.
Каждый процесс получает определённое количество шагов выполнения («редукций»), после чего управление передаётся другому процессу.
Процессы распределяются по двум очередям: готовых к выполнению (ready) и ожидающих ресурсов (waiting).
Реализована технология перераспределения нагрузок («краже задач») для балансировки активности.
Используется структура типа «колеса времени»: массив временных интервалов для хранения активных таймеров с целью снижения накладных расходов.

📌 Типичная ошибка: Долгие встроенные функции (BIFs), выполняемые без передачи управления, способны заблокировать работу планировщика.

2. Сборка мусора: Чистота в памяти 🧹

Сборщик мусора (GC) в среде выполнения BEAM действует подобно аккуратному дворнику, незаметно обходящему рестораны большого города BEAM и аккуратно собирающему грязную посуду, освобождая пространство на столах.

Каждый отдельный процесс имеет свою собственную зону хранения («кучу»). Когда память конкретного процесса заполняется ненужными объектами, уборка проводится именно там, не затрагивая работу остальных процессов.

BEAM применяет методику поколений (generational garbage collection): часто очищаются недавно созданные элементы («молодое поколение»), поскольку они имеют короткий срок жизни, тогда как старшие поколения проверяются гораздо реже.

📌 Типичная ошибка: длительное накопление долгоживущих объектов может привести к повышенному потреблению ресурсов, отслеживайте параметр high_water.

Объёмные двоичные данные (файлы, изображения) располагаются обособленно от основной зоны сборки мусора, предотвращая её чрезмерное заполнение.

📖 Пример из практики: Discord обслуживает миллионы активных каналов на платформе BEAM. Даже если один конкретный чат накапливает временные данные, система очистки мгновенно избавляется от них, абсолютно не влияя на производительность других чатов.

Алгоритм работы:

Стек и куча расширяются навстречу друг другу до тех пор, пока не встретятся. Тогда запускается процедура уборки.
Существуют два типа циклов сбора мусора: молодой (частый, минорный) и старый (редкий, полный).
Используется техника копирования данных между двумя зонами памяти ("from space" → "to space"), обеспечивая эффективную обработку совместно используемых элементов. Ключевые параметры мониторинга: gen_gcs, high_water.

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

3. Архитектура на основе регистров: быстрее и эффективнее 🧠

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

Примеры: Простое вычисление суммы двух чисел (add(A, B) → результат в регистрах X0 и X1).

Принцип функционирования:

Регистры X (до 1024 штук): Хранят аргументы функций.
Регистры Y: Для локальных переменных.
Используются инструкции типа move и call, поддерживается прямая адресация памяти. Технология JIT существенно повышает производительность.

📌 Типичная ошибка: Переполнение регистров — важно следить за размером функций и корректностью оптимизации.

✨ Советы по улучшению производительности: Уменьшайте использование стека, активно задействуйте регистры для хранения промежуточных значений.

4. Супервизоры и отказоустойчивость: Пусть падает! 💥

В обычной среде крах процесса означает бедствие. Но в виртуальной машине BEAM это заложено в философию разработки.

Возьмём аналогию электрической сети: Есть большая электрическая сеть. В ней одна подстанция «вырубилась». В обычном случае — весь район без света. В BEAM же стоит автоматика: неисправная подстанция отключается, а система мгновенно подключает резервную. Город даже не моргнёт лампочкой.

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

Подобная архитектура обеспечивает автоматическое восстановление работоспособности всей системы.

Механизм работы: дерево супервизоров, стратегии типа one_for_one, состояния выполнения (running, сбор мусора).

📌 Типичная ошибка: игнорирование роли супервизора, использование неподходящих инструментов вроде самодельных решений вместо проверенных библиотек OTP.

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

5. Динамическая загрузка кода и распределенные системы 🌍

Платформа BEAM позволяет обновлять код прямо на лету, когда приложение активно функционирует. Подобно тому, как музыкант переключается на другой инструмент посреди выступления, абсолютно незаметно для аудитории.

В BEAM одновременно хранятся две версии каждого модуля: одна старая продолжает обрабатывать существующие запросы, другая новая принимает новые задачи. Таким образом исправляются ошибки и добавляются функции без остановок работы приложения.
Замена кода: выполняется командой :code.load_file(Module). Важно соблюдать правила обновления, иначе возможны сбои.
Распределенность: Проверяется доступность удаленных нод через команду net_adm:ping(Node), база данных поддерживается системой Mnesia. Пример реализации — кластеры в Kubernetes с использованием виртуальных машин на основе BEAM.
Масштабирование: Использование инструментов из набора OTP для мониторинга состояния узлов сети.

6. Масштабируемость: BEAM-сеть на тысячи узлов 🌐

BEAM представляет собой не единый узел, а целую взаимосвязанную сеть, функционирующую как единое целое. Каждый отдельный элемент сети способен взаимодействовать с остальными узлами так, словно они являются частью единой распределённой инфраструктуры.

Вот несколько преимуществ такой архитектуры:

Вы можете развернуть кластер из множества серверов, позволяя процессам обмениваться сообщениями между собой прозрачно и эффективно.
Особенно полезно это в системах Internet of Things (IoT) и микросервисных архитектурах, когда доставка сообщений автоматически распределяется BEAM'ом среди нужных серверов.

📖 Пример из практики: компания Pinterest применила эту технологию для отправки уведомлений своим пользователям. По мере роста нагрузки всё, что потребовалось сделать, — добавить дополнительные сервера в кластер.

BEAM в 2025 году: почему стоит обратить внимание? 🚀

Большие объёмы трафика: WhatsApp обслуживает миллионы подключений одновременно.
Масштабируемые микросервисы: простое развертывание и управление в Kubernetes.
Работа в режиме реального времени: Phoenix обеспечивает мгновенные чат-коммуникации.
Надежность и отказоустойчивость: проверена крупными финансовыми компаниями вроде Klarna.
Интернет вещей и машинное обучение: Nerves для устройств IoT и совместимость с TensorFlow через механизм портов.
Перспективы развития: оптимизация производительности благодаря JIT-компиляции и поддержка WebAssembly для веб-приложений.

📖 Пример из практики: Pinterest снизил задержку доставки уведомлений на 50% именно благодаря платформе BEAM.

BEAM — будущее, которое уже здесь! 🌌

На сегодняшний день, в 2025 году, технологии Elixir и Erlang занимают скромное место среди используемых инструментов разработки и не получают должного внимания общественности. Но лично я считаю, что такая ситуация весьма незаслуженна, потому что предлагаемые ими возможности действительно удивительны и оригинальны. Хотя путь освоения и развития проектов на этой платформе может показаться непростым, результат обещает быть потрясающим!

Откройте для себя мир Elixir/Erlang, окунитесь в разработку нового проекта и ощутите всю мощь виртуальной машины BEAM! ✨

От автора

Спасибо большое за интерес к этой статье! Надеюсь, она помогла разобраться, что представляет собой BEAM и зачем она используется. Изначально планировал сделать материал сложнее и добавить больше технических подробностей, однако понял, что вряд ли смогу превзойти книгу The BEAM Book: Understanding the Erlang Runtime System, поэтому решил изложить всё простыми словами.

Speeding up Elixir: integration with native code (NIF, Ports, etc.)

Artyom Molchanov — Wed, 21 May 2025 08:59:32 +0000

⚠️ Important: Before introducing new languages into your project, ensure that your existing Elixir code has been optimized first. In many cases, proper optimization can significantly improve application performance and sometimes yield better results than adding another programming language.

Elixir and Erlang when are excellent languages for developing scalable and fault-tolerant systems. However, there may come times when you need to extract maximum performance or utilize libraries available only in other languages. If you're facing such situations or simply want to explore how to combine two favorite programming languages, this article is for you!

🔍 Search When You Need Native Code Integration

Before diving into technical details, it's important to understand when native code integration should be considered:

1. Compute-intensive Tasks

The BEAM virtual machine excels at concurrency but isn't designed for heavy computations. Consider integrating native code if your bottleneck involves CPU-bound operations:

🧮 Mathematical Calculations—Linear algebra or matrix operations
🔐 Cryptography—Encryption/decryption of large datasets
🎨 Media Processing—Images, videos, audio
🧠 Machine Learning—Model inference, vector operations

2. Hardware Interaction

When low-level access to hardware is required:

📟 Embedded Systems—Raspberry Pi, microcontrollers (Note: While Nerves exists in Elixir, it might fall short)
🎮 Specific Drivers—Unconventional devices
📊 GPU Computing—CUDA, OpenCL

3. Reusing Existing Codebases

🏛️ Proven Libraries on C/C++
📚 Ecosystem Advantages from other languages (e.g., Python for ML)
🔧 Avoid Reinventing the Wheel

4. Profiling and Bottlenecks

Typical signs indicating it's time to consider native code:

# Before Optimization - 1000ms
defmodule SlowModule do
  def process_data(data) do
    # Potential bottleneck candidate for native optimization
    Enum.reduce(data, 0, fn x, acc -> complex_calculation(x) + acc end)
  end

  defp complex_calculation(x) do
    # Imagine CPU-heavy calculations here
    # That don't scale well within BEAM
  end
end

# Exhausted all possible optimizations in Elixir and still slow?
# Perhaps it's time to introduce native code!

Native extensions transform Elixir into an all-purpose tool where BEAM handles everything except critical computations. This opens doors to ML, hardware, video processing, and more speed-critical tasks.

Balance Comparison of Integration Methods

Choosing the right method of integration is crucial for project success. Here's a comparative table of methods with their pros and cons:

Method	Speed	BEAM Safety	Implementation Complexity	Language Support	Communication Overhead	Asynchronicity	Ideal Use Cases использования
NIF	⚡⚡⚡⚡⚡	❌ Dangerous	🔧🔧🔧 Medium	C, C++	None (direct call)	❌ Blocks scheduler	Microservices, lengthy CPU-bound tasks
Dirty NIF	⚡⚡⚡⚡	⚠️ Conditionally Safe	🔧🔧🔧 Medium	C, C++	None (direct call)	✅ Doesn't block primary scheduler	Long computational tasks (>1ms)
Port	⚡⚡	✅✅ Completely Safe	🔧 Simple	Any	High (IPC)	✅ Process isolation	Python, Go, Bash-scripts
Port Driver	⚡⚡⚡⚡	✅ Safe	🔧🔧🔧🔧 Complex	C, C++	Low	✅ Dedicated thread	Video/audio processing
gRPC	⚡⚡	✅✅ Completely Safe	🔧🔧 Medium	Any with gRPC support	Moderate (network)	✅ Separate service	Microservice architecture
Rustler	⚡⚡⚡⚡	✅ Safe	🔧🔧 Medium	Rust	None (direct call)	✅ Supports asynchronous APIs	Alternative to C NIF
Zigler	⚡⚡⚡⚡⚡	✅ Safe	🔧🔧 Medium	Zig	None (direct call)	✅ Safer than standard NIFs	Alternative to C in NIF

Visual Comparison by Key Metrics

Speed:               Safety:               Simplicity:
NIF         █████    Port        █████     Port        █████
Dirty NIF   ████     Dirty NIF   ███       gRPC        ████
Rustler     ████     Rustler     ████      Rustler     ████
Zigler      █████    Zigler      ████      Zigler      ████
Port Driver ████     Port Driver ████      NIF         ███
Port        ██       gRPC        █████     Port Driver █
gRPC        ██       NIF         █         Dirty NIF   ███

Mechanisms Behind Integration

ㅤ

🧠 NIFs — Maximal Performance

Native Implemented Functions (NIFs) offer the fastest way to integrate native code, albeit being the riskiest option. They execute directly in the BEAM scheduler's thread, ensuring lightning-fast execution due to zero overhead.

How Do NIFs Work?

Compilation: Native code (C/Rust/Zig) compiles into a dynamic library (.so, .dll)
Loading: BEAM loads the library during module startup via :erlang.load_nif/2
Direct Execution: Functions run in the same thread as the calling Elixir code

✅ Benefits

Blazing Speed: Calls take approximately 0.1–1 µs (~100–1000× faster than Ports)
Access to BEAM API: Direct interaction with Erlang terms
No Serialization: No encoding/decoding costs
Distribution: Library ships alongside the OTP app

❌ Drawbacks

Risk of VM Crash: Errors in NIF terminate the entire BEAM instance
Scheduler Blocking: Long-running NIFs freeze multithreading
Debugging Difficulty: Memory leaks hard to detect
Platform Dependency: Requires compilation per target architecture

Dirty NIFs — Safer Alternative

With Erlang/OTP 20+, we have Dirty NIFs, which execute in dedicated thread pools, allowing longer computations without blocking the BEAM scheduler.

// Defining a Dirty NIF
static ErlNifFunc nif_funcs[] = {
    {"long_computation", 1, long_computation_nif, ERL_NIF_DIRTY_CPU}
};

Tip: Use ERL_NIF_DIRTY_CPU for CPU-bound ops and ERL_NIF_DIRTY_IO for I/O-bound ones

🔌 Ports — Complete Isolation

Ports provide a safe mechanism for interacting with external programs through standard I/O streams (stdin/stdout). It's the safest form of integration since the external program runs in its own OS process.

How Do Ports Work?

Launch: Elixir spawns an external program as a separate OS process
Communication: Data exchange occurs over stdin/stdout
Isolation: Failure of the external program doesn't affect BEAM

✅ Benefits

Full Safety: Isolation ensures BEAM stability
Language Agnosticism: Works with any programming language
Ease of Debugging: External program can be tested independently
Dependency-Free: No specific BEAM-compatible libraries needed

❌ Downsides

High Overheads: Approximately 100–500 µs per invocation
Serialization Required: Needs conversion of data (usually to JSON)
Blocking Calls: By default blocks the caller process

🚗 Port Drivers — Goldilocks Zone

Port Drivers are high-performance alternatives to Ports, though they require greater complexity. These drivers are written in C and embedded directly into BEAM’s address space, running in separate threads.

How Do Port Drivers Work?

Load: BEAM loads the C library into its memory space
Thread Allocation: Each driver operates in its own thread
Asynchronous Operation: Data exchanges occur via message queues

✅ Benefits

Performance: Significantly faster than regular ports
Safety: Lower risk compared to NIFs
Async Capability: Non-blocking operation supported
Convenience: No need to spawn additional processes

❌ Disadvantages

Complexity: Requires knowledge of Erlang C API
Limited Scope: Only works with C/C++
Less Documentation: Few examples and guides available

🐊 Zigler — Wrapper Around NIFs for Zig

Zigler is a library enabling writing native extensions using the Zig programming language. It integrates the Zig compiler directly into the Elixir compilation cycle, allowing direct coding in Zig inside Elixir modules.

✅ Benefits

Minimal overhead for native calls
Memory safety without garbage collection
Direct access to low-level operations
Simpler compilation compared to other native extensions
Hot reloading capability

❌ Disadvantages

Zig is relatively young with a smaller community
Higher entry barrier for Elixir developers
Limited ecosystem of libraries compared to Rust

🦀 Rustler — Wrapping NIFs for Rust

Rustler is a library for creating native extensions in Erlang/Elixir using Rust. It provides a safe binding between Rust and Erlang/Elixir, facilitating writing NIFs in Rust.

✅ Benefits

Memory safety enforced at compile-time
High performance for computationally intensive tasks
Rich ecosystem of Rust packages (crates)
Protection against crashes in native code (protects BEAM from crashing)
Parallel execution without blocking the BEAM scheduler

❌ Disadvantages

Complicated build process and dependency management
Requires familiarity with two different programming paradigms
Possible compatibility issues across versions
Potential bottlenecks at runtime boundaries

🌐 Global gRPC and Similar Protocols

For more advanced scenarios involving external services, especially in microservice architectures, protocols like gRPC provide structured and scalable ways of integration.

✅ gRPC Benefits for Elixir

Contract Schema: Strong typing via Protocol Buffers
Bidirectional Streaming: Supports streaming both ways
Cross-platform: Supports multiple languages
Performance: More efficient than REST/JSON

❗️ An example using gRPC was omitted due to its extensive nature. For detailed info about gRPC in Elixir, see elixir-grpc.

🧪 Practical Examples of Integration

📚 The goal of this article is to give an overview of available native integration methods. Deep implementations and edge cases are omitted to maintain balance between theory and practical application.

Exploring Criteria for Choosing Integration Methods

Before moving onto examples, let's define key factors influencing our choice:

Performance: How fast does the call execute?
Safety: Risk level for BEAM stability
Implementation Complexity: Ease of implementation
Language Support: Suitability of the chosen language with BEAM

⚙️ C — Maximum Performance Using NIF and Port Drivers

Optimal Methods:

NIF — for instantaneous operations (<1ms)
Port Drivers — for long-lasting or async tasks

Why Choose This Approach?
C offers seamless compatibility with BEAM, making it ideal for:

Critically performant tasks
Low-level operations (hardware, GPU)
Integrating pre-existing C libraries

Example 1: Fast NIF for Hashing (Best Suited for C)

// hash_nif.c
#include <erl_nif.h>
#include <openssl/sha.h>

static ERL_NIF_TERM sha256_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {
    ErlNifBinary input;
    if (!enif_inspect_binary(env, argv[0], &input)) {
        return enif_make_badarg(env);
    }

    unsigned char hash[SHA256_DIGEST_LENGTH];
    SHA256(input.data, input.size, hash);

    ErlNifBinary output;
    enif_alloc_binary(SHA256_DIGEST_LENGTH, &output);
    memcpy(output.data, hash, SHA256_DIGEST_LENGTH);

    return enif_make_binary(env, &output);
}

static ErlNifFunc nif_funcs[] = {
    {"sha256", 1, sha256_nif}
};

ERL_NIF_INIT(Elixir.CryptoNif, nif_funcs, NULL, NULL, NULL, NULL)

Elixir Part:

defmodule CryptoNif do
  @on_load :load_nif
  def load_nif do
    :erlang.load_nif(Path.expand("./hash_nif"), 0)
  end

  def sha256(_data), do: raise "NIF not loaded!"
end

Compiling C Source:
You'll need the OpenSSL library installed:

# For Ubuntu/Debian
sudo apt-get install libssl-dev

# For CentOS/RHEL
sudo yum install openssl-devel

# For macOS (with Homebrew)
brew install openssl
Compile the C source:


gcc -shared -fPIC -o hash_nif.so hash_nif.c \
  -I /usr/lib/erlang/erts-15.2.7/include \ # Path depends on your system
  -I /usr/include/openssl \
  -L /usr/lib/openssl \
  -lssl -lcrypto

Result:

iex(1)> CryptoNif.sha256("test")
<<159, 134, 208, 129, 136, 76, 125, 101, 154, 47, 234, 160, 197, 90, 208, 21, 163, 191, 79, 27, 43, 11, 130, 44, 209, 93, 108, 21, 176, 240, 10, 8>>

Example 2: Port Driver for String Reversal

// reverse_driver.c
#include "erl_driver.h"
#include <string.h>

typedef struct {
    ErlDrvPort port;
} DriverData;

static void reverse_and_send(ErlDrvData drv_data, char* buf, ErlDrvSizeT len) {
    DriverData* d = (DriverData*)drv_data;

    for (ErlDrvSizeT i = 0; i < len / 2; i++) {
        char temp = buf[i];
        buf[i] = buf[len - 1 - i];
        buf[len - 1 - i] = temp;
    }

    driver_output(d->port, buf, len);
}

static ErlDrvData driver_start(ErlDrvPort port, char* command) {
    DriverData* d = (DriverData*)driver_alloc(sizeof(DriverData));
    d->port = port;
    return (ErlDrvData)d;
}

static void driver_stop(ErlDrvData drv_data) {
    DriverData* d = (DriverData*)drv_data;
    driver_free(d);
}

static ErlDrvEntry driver_entry = {
    .init = NULL,
    .start = driver_start,
    .stop = driver_stop,
    .output = reverse_and_send,
    .ready_input = NULL,
    .ready_output = NULL,
    .driver_name = "reverse_driver",
    .finish = NULL,
    .handle = NULL,
    .control = NULL,
    .timeout = NULL,
    .outputv = NULL,
    .ready_async = NULL,
    .flush = NULL,
    .call = NULL,
    .extended_marker = ERL_DRV_EXTENDED_MARKER,
    .major_version = ERL_DRV_EXTENDED_MAJOR_VERSION,
    .minor_version = ERL_DRV_EXTENDED_MINOR_VERSION,
    .driver_flags = 0,
    .handle2 = NULL,
    .process_exit = NULL,
    .stop_select = NULL
};


DRIVER_INIT(reverse_driver) {
    return &driver_entry;
}

Elixir Part:

defmodule ReverseString do
  def start() do
    :ok = :erl_ddll.load_driver('./', 'reverse_driver')
    Port.open({:spawn, 'reverse_driver'}, [:binary])
  end

  def reverse(port, string) when is_binary(string) do
    true = Port.command(port, string)
    receive do
      {^port, {:data, result}} -> result
    after
      1000 -> {:error, :timeout}
    end
  end

  def stop(port) do
    Port.close(port)
  end
end

Compiling C Source:

gcc -std=gnu99 -shared -fPIC -o reverse_driver.so reverse_driver.c \
    -I/usr/lib/erlang/erts-15.2.7/include/ # Path depends on your system

Result:

iex(1)> port = ReverseString.start
#Port<0.6>
iex(2)> ReverseString.reverse(port, "hello")
"olleh"

🦀 Rustler — Security and Performance with Rustler

Optimal Method: Rustler (specialized wrapper for NIF)

Why Rustler?

Full memory safety
Convenient macros for working with BEAM terms
Automatic error handling
Async task support

Example: Parallel Data Processing

Add Rustler to mix.exs (Current version is 0.36.1):

  defp deps do
    [
      {:rustler, "~> 0.36.1"}
    ]
  end

Create Rust Project Inside Elixir:

mix deps.get
mix rustler.new

This is the name of the Elixir module the NIF module will be registered to.
Module name > RustUtils
This is the name used for the generated Rust crate. The default is most likely fine.
Library name (rustutils) > (Enter)

// lib.rs
use rayon::prelude::*;

#[rustler::nif]
fn parallel_double(input: Vec<i64>) -> Vec<i64> {
    input.par_iter().map(|&x| x * 2).collect()
}

rustler::init!("Elixir.RustUtils");

Elixir Part:

defmodule RustUtils do
  use Rustler, otp_app: :rust_utils, crate: "rustutils"

  def parallel_double(_list), do: :erlang.nif_error(:not_loaded)
end

Result:

RustUtils.parallel_double([1, 2, 3])
# => [2, 4, 6]

3. 🐍 Python — Effortless Integration Through Ports

Optimal Method: Ports

Why Ports?

Total process isolation
Easy debugging
Access to Python ecosystem
Handles long operations (like ML models)

Example: Creating Your Own Model and Integrating TensorFlow

Build the Model:

# create_model.py
import tensorflow as tf
import numpy as np

model = tf.keras.Sequential([
    tf.keras.layers.Dense(1, input_shape=(3,), use_bias=False)
])

model.set_weights([np.array([[1.0], [1.0], [1.0]])])

model.save("my_model.h5")
print("✅ Model saved to my_model.h5")

#tensorflow_port.py
import sys
import json
import numpy as np
import tensorflow as tf
import os

os.environ['TF_CPP_MIN_LOG_LEVEL'] = '3'
tf.get_logger().setLevel('ERROR')

model = tf.keras.models.load_model('my_model.h5')

def predict(data):
    try:
        if isinstance(data, str):
            data = json.loads(data)

        input_array = np.array(data, dtype=np.float32).reshape(1, 3)
        prediction = model.predict(input_array)
        return json.dumps({"status": "success", "result": prediction.tolist()})
    except Exception as e:
        return json.dumps({"status": "error", "message": str(e)})

if __name__ == "__main__":
    for line in sys.stdin:
        line = line.strip()
        if not line:
            continue

        try:
            response = predict(line)
            sys.stdout.write(response + "\n")
            sys.stdout.flush()
        except Exception as e:
            error = json.dumps({"status": "error", "message": str(e)})
            sys.stdout.write(error + "\n")
            sys.stdout.flush()

Elixir Part:

defmodule TensorflowPort do
  @timeout 5_000

  def start do
    Port.open(
      {:spawn, "python3 tensorflow_port.py"},
      [:binary, :use_stdio, :exit_status, :stderr_to_stdout, {:line, 1024}]
    )
  end

  def predict(port, input_data) do
    input_data
    |> Jason.encode!()
    |> then(&Port.command(port, &1 <> "\n"))

    wait_for_response(port)
  end

  defp wait_for_response(port) do
    receive do
      {^port, {:data, {:eol, line}}} ->
        case Jason.decode(line) do
          {:ok, %{"status" => "success", "result" => result}} -> {:ok, result}
          {:ok, %{"status" => "error", "message" => msg}} -> {:error, msg}
          _ -> wait_for_response(port)
        end

      {^port, {:exit_status, status}} ->
        {:error, "Python process exited with status #{status}"}
    after
      @timeout -> {:error, :timeout}
    end
  end
end

Result:

To run the script, enter the Python environment and launch iex -S mix.

(venv)
iex(1)> port = TensorflowPort.start
#Port<0.10>
iex(2)> TensorflowPort.predict(port, [1,2,3])
{:ok, [[6.0]]}

4. 🦫 Go — Efficiency Through CGO or gRPC

Optimal Methods:

CGO wrappers for NIF — best for max performance
gRPC — suitable for complex interactions and microservices

CGO Wrapper for Go Code (Suitable for Performance)

// fib.go
package main

import "C"

func GoFib(n C.int) C.int {
    a, b := 0, 1
    for i := 0; i < int(n); i++ {
        a, b = b, a+b
    }
    return C.int(a)
}

func main() {}

C Wrapper:

// c_src/go_nif.c
#include <erl_nif.h>
#include "libfib.h"

static ERL_NIF_TERM go_fib_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {
    int n;
    if (!enif_get_int(env, argv[0], &n)) {
        return enif_make_badarg(env);
    }
    return enif_make_int(env, GoFib(n));
}

static ErlNifFunc nif_funcs[] = {
    {"go_fib", 1, go_fib_nif}
};

ERL_NIF_INIT(Elixir.NifGo, nif_funcs, NULL, NULL, NULL, NULL)

Elixir part:

defmodule NifGo do
  @on_load :load_nif

  def load_nif do
    nif_path = Path.expand("priv/go_nif", File.cwd!())

    # Preload Go library
    :erlang.load_nif(Path.expand("priv/libfib", File.cwd!()), 0)

    # Load main NIF library
    :erlang.load_nif(nif_path, 0)
  end

  def go_fib(_n), do: raise("NIF not loaded!")
end

Compile:

go build -buildmode=c-shared -o priv/libfib.so fib.go

gcc -shared -fPIC \
    -I/usr/lib/erlang/erts-15.2.7/include/ \ # Path varies based on your system
    -I./priv \
    -o priv/go_nif.so \
    c_src/go_nif.c \
    ./priv/libfib.so \
    -Wl,-rpath,'$ORIGIN'

LD_LIBRARY_PATH=./priv iex -S mix

Run:

iex(1)> NifGo.go_fib(3)
2

⚠️ If you'd rather avoid dealing with CGO, opt for gRPC or Ports instead. They're safer, although slower.

5. 🐊 Zig — Integration Via Zigler

Optimal Method: Zigler (wrapper for Zig-based NIFs)

Why Zigler?

Minimum overhead for native calls
Memory safety without garbage collection
Direct access to low-level operations
Simplified compilation relative to other native extensions
Hot-reloading capabilities

Example: Quick Binary Data Handling

Add Zigler to mix.exs:

def deps do
  [
    {:zigler, "~> 0.13.2", runtime: false}
  ]
end

lib/nif_zig.ex:

defmodule NifZig do
  use Zig, otp_app: :zigler

  ~Z"""
  pub fn string_count(string: []u8) i64 {
    return @intCast(string.len);
  }

  pub fn list_sum(array: []f64) f64 {
    var sum: f64 = 0.0;
    for(array) | item | {
      sum += item;
    }
    return sum;
  }
  """
end

Result:

iex(3)> NifZig.string_count("hello")
5
iex(4)> NifZig.list_sum([1.2,2.3,3.4,4.5])
11.4

Language	Optimal Method	Alternatives	When To Use
C	NIF, Port Drivers	Ports	Maximum performance
Rust	Rustler (NIF)	-	Safety + performance
Python	Ports	gRPC	Integration with ML/scientific tools
Go	C-обёртки (NIF), gRPC	Ports	Leveraging Go ecosystem
Zig	Zigler (NIF)	-	Modern alternative to C

Final Thoughts

Integrating Elixir with native code unlocks new possibilities for developers, combining BEAM's strengths (scalability, reliability) with the performance and libraries of other languages. We've explored various integration techniques: NIF, Dirty NIF, Ports, Port Drivers, Rustler, Zigler, and gRPC, along with their optimal usage scenarios.

Remember, choosing an integration method should align with your project's requirements regarding performance, security, and ease of development.

Author's Notes

Thank you for reading this article! I hope you've found it insightful learning about ways to integrate other languages into Elixir. Among these options, I found Port Drivers particularly challenging, as crafting one turned out to be quite an adventure, requiring hours of trial-and-error to find the correct approach. Overall, however, integrating other languages into Elixir proved neither difficult nor boring—it was actually fun!

If you spot inaccuracies or have interesting additions, please share them in the comments section. Constructive feedback is always appreciated 😎

Ускоряем Elixir: интеграция с нативным кодом (NIF, Ports и др.)

Artyom Molchanov — Wed, 21 May 2025 02:58:30 +0000

⚠️ Важно: Перед внедрением новых языков в проект сначала убедитесь, что код на Elixir был максимально оптимизирован. В большинстве случаев грамотная оптимизация текущего кода значительно улучшает производительность приложения и иногда даёт лучшие результаты, нежели добавление другого языка программирования.

Elixir и Erlang — отличные языки для разработки масштабируемых и отказоустойчивых систем. Но иногда нужно выжать максимум производительности или использовать библиотеку, доступную лишь на другом языке. Если вы попали именно в такую ситуацию или просто хотите узнать, как совместить два ваших любимых языка программирования, эта статья для вас!

🔍 Когда нужна интеграция с нативным кодом

Прежде чем углубляться в технические детали, важно понять, когда стоит рассматривать интеграцию с нативным кодом:

1. Вычислительно-интенсивные задачи

BEAM создан для конкурентности, а не для вычислений. Если ваше узкое место — CPU-bound операции:

🧮 Математические вычисления — Линейная алгебра или операции с матрицами
🔐 Криптография — Шифрование/Дешифрование больших объёмов данных
🎨 Обработка медиа — Изображения, видео, аудио
🧠 Машинное обучение - инференс моделей, векторные операции

2. Аппаратное взаимодействие

Когда требуется низкоуровневый доступ к оборудованию:

📟 Embedded-системы — Raspberry Pi, микроконтроллеры (Для этого есть Nerves в Elixir, но его иногда может не хватить)
🎮 Специфические драйверы — нестандартные устройства
📊 GPU-вычисления — CUDA, OpenCL

3. Переиспользование существующего кода

🏛️ Проверенные временем библиотеки на C/C++
📚 Экосистемные преимущества других языков (например, Python для ML)
🔧 Избегание "изобретения велосипеда"

4. Профилирование и узкие места

Типичные признаки, что пора задуматься о нативном коде:

# До оптимизации - 1000мс
defmodule SlowModule do
  def process_data(data) do
    # Потенциальное узкое место для нативной оптимизации
    Enum.reduce(data, 0, fn x, acc -> complex_calculation(x) + acc end)
  end

  defp complex_calculation(x) do
    # Представьте CPU-интенсивные вычисления
    # которые плохо масштабируются в BEAM
  end
end

# Вы исчерпали возможности оптимизации на Elixir и всё ещё медленно? 
# Возможно, пора подключать нативный код!

Нативные расширения превращают Elixir в универсальный инструмент, где BEAM решает всё, кроме критических вычислений. Это открывает двери к ML, hardware, видеообработке и всему, где важна скорость.

⚖️ Сравнение методов интеграции

Выбор правильного метода интеграции критически важен для успеха проекта. Вот сравнительная таблица методов интеграции с их плюсами и минусами:

Метод	Скорость	Безопасность BEAM	Сложность реализации	Поддержка языков	Коммуникационные затраты	Асинхронность	Идеальные сценарии использования
NIF	⚡⚡⚡⚡⚡	❌ Опасно	🔧🔧🔧 Средняя	C, C++	Нет (прямой вызов)	❌ Блокирует планировщик	Микросервисы, долгие CPU-bound задачи
Dirty NIF	⚡⚡⚡⚡	⚠️ Условно безопасно	🔧🔧🔧 Средняя	C, C++	Нет (прямой вызов)	✅ Не блокирует основной планировщик	Долгие вычисления (>1ms)
Port	⚡⚡	✅✅ Полностью безопасно	🔧 Простая	Любой	Высокие (IPC)	✅ Процессная изоляция	Python, Go, Bash-скрипты
Port Driver	⚡⚡⚡⚡	✅ Безопасно	🔧🔧🔧🔧 Сложная	C, C++	Низкие	✅ Выделенный поток	Обработка видео/аудио
gRPC	⚡⚡	✅✅ Полностью безопасно	🔧🔧 Средняя	Любой с поддержкой gRPC	Средние (сеть)	✅ Отдельный сервис	Микросервисная архитектура
Rustler	⚡⚡⚡⚡	✅ Безопасно	🔧🔧 Средняя	Rust	Нет (прямой вызов)	✅ Поддержка асинхронного API	Альтернатива C NIF
Zigler	⚡⚡⚡⚡⚡	✅ Безопасно	🔧🔧 Средняя	Zig	Нет (прямой вызов)	✅ Безопаснее стандартных NIF	Альтернатива C в NIF

Визуальное сравнение по ключевым метрикам

Скорость:            Безопасность:         Простота:
NIF         █████    Port        █████     Port        █████
Dirty NIF   ████     Dirty NIF   ███       gRPC        ████
Rustler     ████     Rustler     ████      Rustler     ████
Zigler      █████    Zigler      ████      Zigler      ████
Port Driver ████     Port Driver ████      NIF         ███
Port        ██       gRPC        █████     Port Driver █
gRPC        ██       NIF         █         Dirty NIF   ███

🛠️ Немного о механизмах интеграции

ㅤ

🧠 NIFs — максимальная производительность

Native Implemented Functions (NIFs) — самый быстрый способ интеграции, но и самый опасный. Они выполняются напрямую в потоке планировщика BEAM, обеспечивая молниеносную скорость за счет отсутствия накладных расходов.

Как работают NIF?

Компиляция: Нативный код (C/Rust/Zig) компилируется в динамическую библиотеку (.so, .dll)
Загрузка: BEAM загружает библиотеку при старте модуля через :erlang.load_nif/2
Прямое выполнение: Функции выполняются в том же потоке, что и вызывающий Elixir-код

✅ Преимущества

Молниеносная скорость: Вызов занимает ~0.1-1 μs (в 100-1000 раз быстрее Ports)
Доступ к BEAM API: Прямая работа с термами Erlang
Отсутствие сериализации: Нет накладных расходов на кодирование/декодирование данных
Распространение: Библиотека идёт вместе с OTP-приложением

❌ Недостатки

Риск падения всей ВМ: Ошибка в NIF убьёт весь BEAM
Блокировка планировщика: Долгие NIF замораживают многопоточность
Сложность отладки: Трудно обнаружить утечки памяти
Платформозависимость: Требуется компиляция под каждую архитектуру

Dirty NIFs — безопасная альтернатива

С Erlang/OTP 20+ появились Dirty NIFs — специальный вид NIF, который исполняется в выделенном пуле потоков, что позволяет выполнять долгие вычисления без блокировки планировщика BEAM.

// Определение Dirty NIF
static ErlNifFunc nif_funcs[] = {
    {"long_computation", 1, long_computation_nif, ERL_NIF_DIRTY_CPU}
};

💡 Совет: Используйте ERL_NIF_DIRTY_CPU для CPU-bound операций и ERL_NIF_DIRTY_IO для операций ввода/вывода

🔌 Ports — полная изоляция

Ports — способ для взаимодействия с внешними программами через стандартные потоки ввода-вывода (stdin/stdout). Это самый безопасный способ интеграции, так как внешняя программа запускается в отдельном процессе ОС.

Как работают Ports?

Запуск: Elixir запускает внешнюю программу как отдельный OS-процесс
Обмен данными: Коммуникация через стандартные потоки (stdin/stdout)
Изоляция: Падение внешней программы не влияет на BEAM

✅ Преимущества

Полная безопасность: Изоляция гарантирует стабильность BEAM
Языковая агностичность: Работает с любым языком программирования
Простота отладки: Внешнюю программу можно тестировать отдельно
Отсутствие зависимостей: Не требует специфичных для BEAM библиотек

❌ Недостатки

Высокие накладные расходы: ~100-500 μs на вызов
Сериализация: Требуется преобразование данных (обычно в JSON)
Блокирующие вызовы: По умолчанию блокирует вызывающий процесс

🚗 Port Drivers — золотая середина

Port Drivers — производительная альтернатива Ports, но более сложная. Это драйверы на языке C, встроенные непосредственно в адресное пространство BEAM и работающие в отдельных потоках.

Как работают Port Drivers?

Загрузка: BEAM загружает C-библиотеку в свое адресное пространство
Выделение потока: Драйвер работает в отдельном потоке
Асинхронность: Обмен данными через очередь сообщений

✅ Преимущества

Скорость: Значительно быстрее обычных портов
Безопасность: Меньший риск чем у NIF
Асинхронность: Поддержка неблокирующих операций
Удобство: Не требует запуска отдельного процесса

❌ Недостатки

Сложность: Требует знания C API Erlang
Ограниченность: Работает только с C/C++
Меньшая документация: Не так много примеров и руководств

🐊 Zigler - Обёртка над NIFs для Zig

Zigler — Библиотека, позволяющая писать нативные расширения на языке Zig. Встраивает компилятор Zig прямо в цикл компиляции Elixir и позволяет напрямую писать код на Zig в модулях Elixir

✅ Преимущества

Минимальные накладные расходы на вызов нативного кода
Безопасность памяти без сборщика мусора
Прямой доступ к низкоуровневым операциям
Более простая компиляция в сравнении с другими нативными расширениями
Поддержка горячей перезагрузки кода

❌ Недостатки

Zig — относительно молодой язык с меньшим сообществом
Более высокий порог входа для разработчиков Elixir
Ограниченная экосистема библиотек в сравнении с Rust

Rustler - Обёртка над NIFs для Rust

Rustler — это библиотека для создания нативных расширений Erlang/Elixir на языке Rust. Обеспечивает безопасный биндинг между Rust и Erlang/Elixir, позволяя писать NIFs на Rust.

✅ Преимущества

Безопасность памяти на уровне компиляции
Высокая производительность для вычислительно сложных задач
Богатая экосистема пакетов Rust (crates)
Защита от сбоев в нативном коде (защита BEAM от падения)
Параллельное выполнение без блокировки планировщика BEAM

❌ Недостатки

Усложненный процесс сборки и зависимостей
Требует знания двух различных парадигм программирования
Возможные проблемы с совместимостью версий
Потенциальные узкие места на границе сред выполнения

🌐 gRPC и другие протоколы

Для более сложных сценариев взаимодействия с внешними сервисами, особенно в микросервисной архитектуре, gRPC и подобные протоколы предоставляют структурированный и масштабируемый способ интеграции.

✅ Преимущества gRPC для Elixir

Схема контрактов: Строгие типы через Protocol Buffers
Двунаправленный стриминг: Поддержка потоковой передачи в обе стороны
Кросс-платформенность: Поддержка множества языков
Производительность: Более эффективен чем REST/JSON

❗️Пример с gRPC был слишком объёмен, чтобы рассмотреть его в рамках этой статьи, из-за чего он не был включён в неё. Подробнее о gRPC на Elixir можно почитать вот тут - elixir-grpc

🧪 Практические примеры интеграции

📚 Цель статьи — дать обзор доступных способов интеграции с нативным кодом. Глубокие реализации и edge-кейсы здесь опущены, чтобы сохранить баланс между теорией и применением.

🔍 Критерии выбора метода интеграции

Прежде чем перейти к примерам, определим ключевые факторы выбора:

Производительность: Насколько быстро работает вызов
Безопасность: Риск для стабильности BEAM
Сложность реализации: Легко ли внедрить решение
Поддержка языка: Насколько хорошо язык работает с BEAM

1. ⚙️ C — максимальная производительность с NIF и Port Drivers

Оптимальные методы:

NIF — для мгновенных операций (<1ms)
Port Drivers — для долгих или асинхронных задач

Почему именно так?

C имеет прямую совместимость с BEAM, что делает его идеальным для:

Критически важных по производительности задач
Низкоуровневых операций (работа с железом, GPU)
Интеграции с существующими C-библиотеками

Пример 1: Быстрый NIF для хеширования (оптимально для C)

// hash_nif.c
#include <erl_nif.h>
#include <openssl/sha.h>

static ERL_NIF_TERM sha256_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {
    ErlNifBinary input;
    if (!enif_inspect_binary(env, argv[0], &input)) {
        return enif_make_badarg(env);
    }

    unsigned char hash[SHA256_DIGEST_LENGTH];
    SHA256(input.data, input.size, hash);

    ErlNifBinary output;
    enif_alloc_binary(SHA256_DIGEST_LENGTH, &output);
    memcpy(output.data, hash, SHA256_DIGEST_LENGTH);

    return enif_make_binary(env, &output);
}

static ErlNifFunc nif_funcs[] = {
    {"sha256", 1, sha256_nif}
};

ERL_NIF_INIT(Elixir.CryptoNif, nif_funcs, NULL, NULL, NULL, NULL)

Elixir часть:

defmodule CryptoNif do
  @on_load :load_nif
  def load_nif do
    :erlang.load_nif(Path.expand("./hash_nif"), 0)
  end

  def sha256(_data), do: raise "NIF not loaded!"
end

Компиляция C-исходника:

Для запуска данного примера вам нужна openssl библиотека

# Для Ubuntu/Debian
sudo apt-get install libssl-dev

# Для CentOS/RHEL
sudo yum install openssl-devel

# Для macOS (если используете Homebrew)
brew install openssl

gcc -shared -fPIC -o hash_nif.so hash_nif.c \
  -I /usr/lib/erlang/erts-15.2.7/include \ # Путь до Erlang зависит от вашей системы
  -I /usr/include/openssl \
  -L /usr/lib/openssl \
  -lssl -lcrypto

Результат:

iex(1)> CryptoNif.sha256("test")
<<159, 134, 208, 129, 136, 76, 125, 101, 154, 47, 234, 160, 197, 90, 208, 21, 163, 191, 79, 27, 43, 11, 130, 44, 209, 93, 108, 21, 176, 240, 10, 8>>

Пример 2: Port Driver для реверса строки

// reverse_driver.c
#include "erl_driver.h"
#include <string.h>

typedef struct {
    ErlDrvPort port;
} DriverData;

static void reverse_and_send(ErlDrvData drv_data, char* buf, ErlDrvSizeT len) {
    DriverData* d = (DriverData*)drv_data;

    for (ErlDrvSizeT i = 0; i < len / 2; i++) {
        char temp = buf[i];
        buf[i] = buf[len - 1 - i];
        buf[len - 1 - i] = temp;
    }

    driver_output(d->port, buf, len);
}

static ErlDrvData driver_start(ErlDrvPort port, char* command) {
    DriverData* d = (DriverData*)driver_alloc(sizeof(DriverData));
    d->port = port;
    return (ErlDrvData)d;
}

static void driver_stop(ErlDrvData drv_data) {
    DriverData* d = (DriverData*)drv_data;
    driver_free(d);
}

static ErlDrvEntry driver_entry = {
    .init = NULL,
    .start = driver_start,
    .stop = driver_stop,
    .output = reverse_and_send,
    .ready_input = NULL,
    .ready_output = NULL,
    .driver_name = "reverse_driver",
    .finish = NULL,
    .handle = NULL,
    .control = NULL,
    .timeout = NULL,
    .outputv = NULL,
    .ready_async = NULL,
    .flush = NULL,
    .call = NULL,
    .extended_marker = ERL_DRV_EXTENDED_MARKER,
    .major_version = ERL_DRV_EXTENDED_MAJOR_VERSION,
    .minor_version = ERL_DRV_EXTENDED_MINOR_VERSION,
    .driver_flags = 0,
    .handle2 = NULL,
    .process_exit = NULL,
    .stop_select = NULL
};


DRIVER_INIT(reverse_driver) {
    return &driver_entry;
}

Elixir часть:

defmodule ReverseString do
  def start() do
    :ok = :erl_ddll.load_driver('./', 'reverse_driver')
    Port.open({:spawn, 'reverse_driver'}, [:binary])
  end

  def reverse(port, string) when is_binary(string) do
    true = Port.command(port, string)
    receive do
      {^port, {:data, result}} -> result
    after
      1000 -> {:error, :timeout}
    end
  end

  def stop(port) do
    Port.close(port)
  end
end

Компиляция C-исходника:

gcc -std=gnu99 -shared -fPIC -o reverse_driver.so reverse_driver.c \
    -I/usr/lib/erlang/erts-15.2.7/include/ # Путь до Erlang зависит от вашей системы

Результат:

iex(1)> port = ReverseString.start
#Port<0.6>
iex(2)> ReverseString.reverse(port, "hello")
"olleh"

2. 🦀 Rust — безопасность и производительность с Rustler

Оптимальный метод: Rustler (специализированная обёртка над NIF)

Почему Rustler?

Полная безопасность памяти
Удобные макросы для работы с BEAM терминами
Автоматическая обработка ошибок
Поддержка асинхронных задач

Пример: Параллельная обработка данных

Добавляем в mix.exe Rustler (На данный момент актуальная версия - 0.36.1)

  defp deps do
    [
      {:rustler, "~> 0.36.1"}
    ]
  end

Добавляем Rust-проект в Elixir

mix deps.get
mix rustler.new

This is the name of the Elixir module the NIF module will be registered to.
Module name > RustUtils
This is the name used for the generated Rust crate. The default is most likely fine.
Library name (rustutils) > # Тут просто нажимаем Enter (Ну или переименуйте на более удобное название)

// lib.rs
use rayon::prelude::*;

#[rustler::nif]
fn parallel_double(input: Vec<i64>) -> Vec<i64> {
    input.par_iter().map(|&x| x * 2).collect()
}

rustler::init!("Elixir.RustUtils");

Elixir часть:

defmodule RustUtils do
  use Rustler, otp_app: :rust_utils, crate: "rustutils"

  def parallel_double(_list), do: :erlang.nif_error(:not_loaded)
end

Результат:

RustUtils.parallel_double([1, 2, 3])
# => [2, 4, 6]

3. 🐍 Python — простота интеграции через Ports

Оптимальный метод: Ports

Почему Ports?

Полная изоляция процессов
Простота отладки
Доступ ко всему Python-экосистеме
Поддержка долгих операций (ML модели и т.д.)

Пример: Создание своей модели и интеграция с TensorFlow

Создаём модель

# create_model.py
import tensorflow as tf
import numpy as np

model = tf.keras.Sequential([
    tf.keras.layers.Dense(1, input_shape=(3,), use_bias=False)
])

model.set_weights([np.array([[1.0], [1.0], [1.0]])])

model.save("my_model.h5")
print("✅ Model saved to my_model.h5")

#tensorflow_port
import sys
import json
import numpy as np
import tensorflow as tf
import os

os.environ['TF_CPP_MIN_LOG_LEVEL'] = '3'
tf.get_logger().setLevel('ERROR')

model = tf.keras.models.load_model('my_model.h5')

def predict(data):
    try:
        if isinstance(data, str):
            data = json.loads(data)

        input_array = np.array(data, dtype=np.float32).reshape(1, 3)
        prediction = model.predict(input_array)
        return json.dumps({"status": "success", "result": prediction.tolist()})
    except Exception as e:
        return json.dumps({"status": "error", "message": str(e)})

if __name__ == "__main__":
    for line in sys.stdin:
        line = line.strip()
        if not line:
            continue

        try:
            response = predict(line)
            sys.stdout.write(response + "\n")
            sys.stdout.flush()
        except Exception as e:
            error = json.dumps({"status": "error", "message": str(e)})
            sys.stdout.write(error + "\n")
            sys.stdout.flush()

Elixir часть:

defmodule TensorflowPort do
  @timeout 5_000

  def start do
    Port.open(
      {:spawn, "python3 tensorflow_port.py"},
      [:binary, :use_stdio, :exit_status, :stderr_to_stdout, {:line, 1024}]
    )
  end

  def predict(port, input_data) do
    input_data
    |> Jason.encode!()
    |> then(&Port.command(port, &1 <> "\n"))

    wait_for_response(port)
  end

  defp wait_for_response(port) do
    receive do
      {^port, {:data, {:eol, line}}} ->
        case Jason.decode(line) do
          {:ok, %{"status" => "success", "result" => result}} -> {:ok, result}
          {:ok, %{"status" => "error", "message" => msg}} -> {:error, msg}
          _ -> wait_for_response(port)
        end

      {^port, {:exit_status, status}} ->
        {:error, "Python process exited with status #{status}"}
    after
      @timeout -> {:error, :timeout}
    end
  end
end

Результат:

Для работы программы нужно будет зайти в Python-окружение и оттуда запустить iex -S mix

(venv)
iex(1)> port = TensorflowPort.start
#Port<0.10>
iex(2)> TensorflowPort.predict(port, [1,2,3])
{:ok, [[6.0]]}

4. 🐹 Go — эффективность через C-обёртки или gRPC

Оптимальные методы:

C-обёртки для NIF — когда нужна максимальная производительность
gRPC — для сложных взаимодействий и микросервисов

C-обёртка для Go кода (оптимально для производительности)

// fib.go
package main

import "C"

func GoFib(n C.int) C.int {
    a, b := 0, 1
    for i := 0; i < int(n); i++ {
        a, b = b, a+b
    }
    return C.int(a)
}

func main() {}

C-обёртка:

// c_src/go_nif.c
#include <erl_nif.h>
#include "libfib.h"

static ERL_NIF_TERM go_fib_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {
    int n;
    if (!enif_get_int(env, argv[0], &n)) {
        return enif_make_badarg(env);
    }
    return enif_make_int(env, GoFib(n));
}

static ErlNifFunc nif_funcs[] = {
    {"go_fib", 1, go_fib_nif}
};

ERL_NIF_INIT(Elixir.NifGo, nif_funcs, NULL, NULL, NULL, NULL)

Elixir часть:

defmodule NifGo do
  @on_load :load_nif

  def load_nif do
    nif_path = Path.expand("priv/go_nif", File.cwd!())

    # Предварительная загрузка Go-библиотеки
    :erlang.load_nif(Path.expand("priv/libfib", File.cwd!()), 0)

    # Загрузка основной NIF-библиотеки
    :erlang.load_nif(nif_path, 0)
  end

  def go_fib(_n), do: raise("NIF not loaded!")
end

Результат:

go build -buildmode=c-shared -o priv/libfib.so fib.go

gcc -shared -fPIC \
    -I/usr/lib/erlang/erts-15.2.7/include/ \ # Путь до Erlang зависит от вашей системы
    -I./priv \
    -o priv/go_nif.so \
    c_src/go_nif.c \
    ./priv/libfib.so \
    -Wl,-rpath,'$ORIGIN'

LD_LIBRARY_PATH=./priv iex -S mix

iex(1)> NifGo.go_fib(3)
2

⚠️ Если вам не хочется возиться с компиляцией и ABI, можно использовать gRPC или Ports вместо cgo. Это безопаснее, хоть и медленнее.

5. ⚡ Zig — Интеграция через Zigler

Оптимальный метод: Zigler (специализированная обёртка для Zig)

Почему Zigler?

Простота как у Rustler
Производительность как у C
Современные фичи языка (comptime, etc.)
Безопаснее чистого C

Пример: Быстрая обработка бинарных данных

Добавьте Zigler в mix.exe:

def deps do
  [
    {:zigler, "~> 0.13.2", runtime: false}
  ]
end

lib/nif_zig.ex:

defmodule NifZig do
  use Zig, otp_app: :zigler

  ~Z"""
  pub fn string_count(string: []u8) i64 {
    return @intCast(string.len);
  }

  pub fn list_sum(array: []f64) f64 {
    var sum: f64 = 0.0;
    for(array) | item | {
      sum += item;
    }
    return sum;
  }
  """
end

Результат:

iex(3)> NifZig.string_count("hello")
5
iex(4)> NifZig.list_sum([1.2,2.3,3.4,4.5])
11.4

📊 Сводная таблица оптимальных методов

Язык	Оптимальный метод	Альтернативы	Когда использовать
C	NIF, Port Drivers	Ports	Максимальная производительность
Rust	Rustler (NIF)	-	Безопасность + производительность
Python	Ports	gRPC	Интеграция с ML/научными библиотеками
Go	C-обёртки (NIF), gRPC	Ports	Использование Go-экосистемы
Zig	Zigler (NIF)	-	Современная альтернатива C

😴 Заключение

Интеграция Elixir с нативным кодом открывает новые горизонты для разработчиков, позволяя сочетать преимущества BEAM (масштабируемость, отказоустойчивость) с производительностью и библиотеками других языков. В статье мы рассмотрели ключевые методы интеграции: NIF, Dirty NIF, Ports, Port Drivers, Rustler, Zigler и gRPC, а также их оптимальные сценарии использования.

Помните, что выбор метода интеграции должен основываться на конкретных требованиях вашего проекта к производительности, безопасности и простоте разработки.

От автора

Благодарю вас за внимание к данной статье! Надеюсь, вам было интересно узнать про способы интеграции других языков в Elixir. Из всех вариантов мне показался наиболее сложным Port Drivers, потому что создание одного такого драйвера само по себе превращается в настоящий квест, успешно завершённый лишь после нескольких часов подбора подходящих методов на C. В остальном, интеграция других языков в Elixir оказалась вовсе несложной, скорее даже увлекательной.

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

Для тех, кому интересно глубже погрузиться в мир технологий, архитектуры и разработки, приглашаю заглянуть в мой телеграм-канал 🖥, где я делюсь рецензиями на технические книги, полезными материалами по Elixir и не только 🤤

Elixir for Machine Learning. Part 1 - Theory

Artyom Molchanov — Wed, 02 Apr 2025 14:52:26 +0000

In recent times, the role of artificial intelligence in various fields has been gaining momentum. Many companies are already implementing AI to assist users on their portals, while others are developing their own neural networks to solve specialized tasks

While Python dominates the ML landscape, Elixir finds its niche in specific areas: real-time data processing systems (Bumblebee), model inference services (Nx.Serving), and distributed machine learning systems. Companies such as DockYard and Dashbit have successfully implemented ML solutions using Elixir in industrial environments

This article is divided into two parts — Theory and Practice. In the first part, we will explore the basics of machine learning, familiarize ourselves with key concepts, and learn about libraries that help create neural networks using Elixir

What Are Machine Learning and Neural Networks?

Machine Learning (ML) is an approach to creating systems that can learn from data and improve performance over time without explicit programming. Instead of writing specific instructions to solve a task, we build models that adapt and "learn" based on experience.

Neural networks are one of the most popular methods in machine learning, inspired by how the human brain works. They consist of interconnected nodes (neurons), organized into layers:

The input layer receives raw data (e.g., image pixels)
Hidden layers process information, identifying increasingly complex patterns
The output layer provides the final result (e.g., object classification)

Each neuron takes input signals, processes them by applying an activation function to the weighted sum of inputs, and passes the result along the network. Connections between neurons carry weight coefficients that determine signal importance.

The training process involves adjusting these weights so that the network produces accurate results. This happens through:

Feeding many training examples
Calculating the error between the network's predictions and actual values
Adjusting weights to minimize this error using the backpropagation algorithm

Key Concepts in Machine Learning

Models and Their Types

Model — a mathematical or algorithmic construct that learns from data to perform a specific task. Models come in various types:

Linear models: Relatively simple models that assume a linear relationship between input and output data. Examples: linear regression, logistic regression
Neural networks: Multi-layered models capable of identifying complex nonlinear dependencies. Used in computer vision, natural language processing, and other complex problems
Ensemble models: Combinations of multiple models to produce more accurate results. Examples: random forests, gradient boosting

Tensors and Their Role in ML

Tensor — a generalization of scalars, vectors, and matrices to multi-dimensional data arrays. Tensors are fundamental data structures in modern machine learning systems:

Scalar: Rank-0 tensor (0-D). Example: the number 5
Vector: Rank-1 tensor (1-D). Example: [1, 2, 3]
Matrix: Rank-2 tensor (2-D). Example: [[1, 2, 3], [4, 5, 6]]
Multi-dimensional tensor: Rank-3+ tensor (3-D and higher). Example: [[[1, 2], [3, 4]], [[5, 6], [7, 8]]]

Tensors are used to represent and process various types of data in ML:

Images (4D tensors: [batch_size, height, width, channels])
Text (sequences of vectors representing words or tokens)
Time series (sequences of observations over time)

Learning Types

Learning — the process by which a model adjusts its parameters based on data:

Supervised Learning: The model learns from labeled data where the correct answer is known for each input example. Example tasks: image classification, price prediction, speech recognition
Unsupervised Learning: The model learns from unlabeled data, uncovering hidden structures and patterns. Example tasks: clustering, dimensionality reduction, anomaly detection
Reinforcement Learning: The model learns by interacting with an environment, receiving rewards or penalties for its actions. Applied in robotics, gaming, autonomous systems

Hyperparameters and Their Tuning

Hyperparameters — model settings defined before training and not altered during the process:

Architectural hyperparameters: Number of layers in a neural network, number of neurons per layer, types of activation functions
Optimization parameters: Learning rate, batch size, number of training epochs
Regularization parameters: L1/L2 regularization coefficients, dropout rate to prevent overfitting

Hyperparameter tuning is typically done using methods like grid search, random search, or Bayesian optimization.

Model Evaluation Metrics

Metrics — quantitative measures used to assess model performance:

For classification tasks:
- Accuracy: Proportion of correct predictions among all predictions
- Precision & Recall: Metrics reflecting the balance between false positives and false negatives
- F1-score: Harmonic mean of precision and recall
- ROC-AUC: Area under the ROC curve, indicating the model's ability to distinguish classes
For regression tasks:
- Mean squared error (MSE): Average of squared differences between predicted and actual values
- Mean absolute error (MAE): Average of absolute differences between predicted and actual values
- Coefficient of determination (R²): Measures how well the model explains data variation

The choice of metric depends on the specific task and business context. For instance, in medical diagnostics, minimizing false negatives is critical, while in recommender systems, the quality of top recommendations may be more important.

Now that we’ve covered the key concepts of machine learning, let’s move on to the tools that enable their application in the Elixir ecosystem.

Elixir Tools for Machine Learning

The machine learning ecosystem in Elixir is rapidly evolving, offering increasingly powerful and developer-friendly tools. Let’s explore the key libraries that enable ML on the BEAM platform.

Numerical Elixir (Nx): The Foundation for Computation

Nx is the backbone of Elixir's ML ecosystem, developed by the Dashbit team under the leadership of José Valim (the creator of Elixir). This library provides high-performance numerical computing and support for multi-dimensional tensors, which are critical for machine learning.

Key Features of Nx:

Tensor operations: A comprehensive set of functions for manipulating multi-dimensional data arrays.
Numerical stability: High-precision computations with error control.
Computation compilation: Transforms Elixir code into optimized machine code.
Automatic differentiation: Essential for backpropagation algorithms.

A particularly powerful feature of Nx is the defn system (definable numerical functions), which compiles computations into efficient low-level code:

defmodule MathOps do  
  import Nx.Defn  

  defn multiply_and_add(a, b, c) do  
    a * b + c  
  end  
end  

# Usage  
x = Nx.tensor([1, 2, 3])  
y = Nx.tensor([4, 5, 6])  
z = Nx.tensor([7, 8, 9])  
MathOps.multiply_and_add(x, y, z)  
# Result: Nx.tensor([11, 18, 27])

Supported Nx Backends:

Nx operates via a backend system that determines where and how computations are executed:

EXLA: Integration with XLA (Accelerated Linear Algebra) from Google, enabling compilation for CPU, GPU, and TPU.
Torchx: Connection to PyTorch, leveraging its optimized CUDA operations.
ONNX: Support for Open Neural Network Exchange for compatibility with a wide range of models.
BinaryBackend: Native Elixir implementation with no external dependencies.

Backend selection depends on the task and available hardware:

# Global use of EXLA backend  
Nx.global_default_backend(EXLA.Backend)  

# Using PyTorch for a specific operation  
Nx.backend_transfer(tensor, {Torchx.Backend, device: :cuda})

Axon: Neural Networks with a Functional Approach

Axon is a high-level framework for defining, training, and evaluating neural networks, built on top of Nx. Its standout feature is its functional design, which aligns perfectly with Elixir's philosophy.

Features of Axon:

Declarative model definition: A clear pipeline approach to architecture design.
Built-in optimizers: Implementations of Adam, SGD, and RMSProp.
Loss functions: A wide range for various tasks (e.g., MSE, cross-entropy).
Training management: Tools for early stopping, validation, and callbacks.

Example of creating and training a classification model:

# Model definition  
model =  
  Axon.input("input", shape: {nil, 784})  
  |> Axon.dense(512)  
  |> Axon.relu()  
  |> Axon.dense(10)  
  |> Axon.softmax()  

# Compilation and training  
trained_model =  
  model  
  |> Axon.Loop.trainer(:categorical_cross_entropy, :adam)  
  |> Axon.Loop.metric(:accuracy)  
  |> Axon.Loop.run(train_data, epochs: 5, compiler: EXLA)

Advanced Capabilities of Axon:

Axon supports a wide range of layers and architectures:

Convolutional layers: For computer vision tasks (Axon.conv).
Recurrent networks: LSTM, GRU for sequential data.
Transformers: Attention mechanisms for NLP.
Normalization: BatchNorm, LayerNorm for training stability.
Regularization: Dropout, L1/L2 to combat overfitting.

Example of a convolutional network for image classification:

model =  
  Axon.input("input", shape: {nil, 1, 28, 28})  
  |> Axon.conv(32, kernel_size: 3, padding: :same)  
  |> Axon.relu()  
  |> Axon.max_pool(kernel_size: 2)  
  |> Axon.conv(64, kernel_size: 3, padding: :same)  
  |> Axon.relu()  
  |> Axon.max_pool(kernel_size: 2)  
  |> Axon.flatten()  
  |> Axon.dense(128)  
  |> Axon.relu()  
  |> Axon.dense(10)  
  |> Axon.softmax()

Explorer: Data Processing and Preparation

Explorer is a library for working with tabular data, inspired by Python's Pandas. It integrates seamlessly with Nx, enabling easy conversion of data into tensors.

Key Features of Explorer:

DataFrame API: Powerful interface for data manipulation.
Filtering and grouping: Efficient handling of large datasets.
Loading/saving: Support for CSV, Parquet, JSON, and other formats.
Visualization: Integration with Vega-Lite for charting.

Example of data processing:

# Loading and processing data  
df = Explorer.DataFrame.from_csv!("titanic.csv")  
  |> Explorer.DataFrame.filter(age > 18)  
  |> Explorer.DataFrame.select(["survived", "age", "sex", "fare"])  
  |> Explorer.DataFrame.mutate(fare_category: apply(fare, fn fare ->  
    cond do  
      fare < 20 -> "low"  
      fare < 50 -> "medium"  
      true -> "high"  
    end  
  end))  

#### Converting to Tensors for ML  
features = Explorer.DataFrame.to_nx(df, ["age", "sex", "fare"])  
labels = Explorer.DataFrame.to_nx(df, ["survived"])

Bumblebee: Pre-trained Models for Practical Use

Bumblebee provides pre-trained models and tools for deploying them, simplifying the use of state-of-the-art models without training from scratch.

Key Features:

Pre-trained models: BERT, GPT-2, ResNet, CLIP, Stable Diffusion, and more.
Built-in pipelines: Ready-made solutions for common tasks.
Hugging Face integration: Access to thousands of models.
Optimized inference: Efficient execution on various hardware.

Example for sentiment analysis:

{:ok, model_info} = Bumblebee.load_model({:hf, "distilbert-base-uncased-finetuned-sst-2-english"})  
{:ok, tokenizer} = Bumblebee.load_tokenizer({:hf, "distilbert-base-uncased"})  

serving = Bumblebee.Text.sentiment(model_info, tokenizer, compile: [batch_size: 1])  

Nx.Serving.run(serving, "I love Elixir, it's an amazing language!")  
# => %{predictions: [%{label: "POSITIVE", score: 0.998}]}

Nx.Serving: Deploying Models in Production

Nx.Serving is a tool for efficiently deploying ML models as services. It offers:

Request batching: Automatic grouping for efficient execution.
Queues and priorities: Workload management and resource allocation.
Hot swapping: Model updates without downtime.
Monitoring: Performance and resource usage tracking.

Example of an image classification service:

model_info = Bumblebee.load_model({:hf, "microsoft/resnet-50"})  
featurizer = Bumblebee.load_featurizer({:hf, "microsoft/resnet-50"})  

serving =  
  Bumblebee.Vision.image_classification(  
    model_info,  
    featurizer,  
    compile: [batch_size: 8],  # Dynamic batching  
    defn_options: [compiler: EXLA]  # GPU acceleration  
  )  

# Running as an OTP process  
{:ok, pid} = Nx.Serving.start_link(serving, name: ImageClassifier)  

# Usage  
{:ok, image} = Image.from_file("cat.jpg")  
Nx.Serving.batched_run(ImageClassifier, image)

LiveBook: Interactive Development and Experimentation

LiveBook is an interactive environment for developing and documenting Elixir code, ideal for ML experiments. It provides:

Jupyter-like interface: Interactive code cells.
Built-in visualization: Charts, graphs, tables.
Integration with ML libraries: Special widgets for Nx, Axon, Explorer.
Collaboration: Share and collaborate on notebooks.
GPU execution: Hardware acceleration support.

LiveBook simplifies learning, experimentation, and documentation for Elixir ML projects:

# Example LiveBook cell  
Mix.install([  
  {:nx, "~> 0.5"},  
  {:axon, "~> 0.5"},  
  {:explorer, "~> 0.5"},  
  {:kino, "~> 0.8"}  
])  

### Interactive hyperparameter input  
form = Kino.Control.form(  
  [  
    learning_rate: Kino.Input.text("Learning rate", default: "0.001"),  
    epochs: Kino.Input.range(1..100, default: 10)  
  ],  
  submit: "Train model"  
)

Scholar: Traditional Machine Learning Algorithms

Scholar extends the Elixir ML ecosystem with classical algorithms, often better suited for certain tasks than deep learning:

Linear models: Regression, SVM, logistic regression.
Decision trees: Single trees and ensembles.
Clustering: K-means, DBSCAN.
Dimensionality reduction: PCA, t-SNE.
Statistical methods: Bayesian models, density estimation.

Example of using linear regression

import Scholar.Linear.LinearRegression
import Nx.Defn

# Data preparation
x = Nx.tensor([[1.0, 1.0], [1.0, 2.0], [2.0, 2.0], [2.0, 3.0]])
y = Nx.tensor([6.0, 8.0, 9.0, 11.0])

# Model training
model = fit(x, y)

# Prediction
predict(model, Nx.tensor([[3.0, 5.0]]))
# => #Nx.Tensor
#  f32[1]
#  [17.0]
# >

Practical Application: Integration with Phoenix

It's worth noting how seamlessly ML models integrate with the Phoenix web framework, enabling powerful intelligent web applications:

defmodule MyAppWeb.MLController do  
  use MyAppWeb, :controller  
  alias Nx.Serving  

  # Model initialization at application start  
  @serving Bumblebee.Text.sentiment(model_info, tokenizer, compile: [batch_size: 4])  
  Serving.start_link(@serving, name: SentimentAnalyzer)  

  def analyze(conn, %{"text" => text}) do  
    # Asynchronous analysis  
    Task.async(fn ->  
      Serving.batched_run(SentimentAnalyzer, text)  
    end)  
    |> Task.await()  
    |> case do  
      %{predictions: [%{label: label, score: score}]} ->  
        json(conn, %{sentiment: label, confidence: score})  
      _ ->  
        conn  
        |> put_status(422)  
        |> json(%{error: "Analysis failed"})  
    end  
  end  
end

This integration makes it easy to create APIs for text analysis, image classification, recommendation systems, and other ML applications while leveraging BEAM's advantages for horizontal scaling and high availability.

The ML ecosystem in Elixir offers a balanced combination of high-level tools and low-level control, allowing developers to choose the right abstraction level for their tasks. While not as extensive as the Python ecosystem, Elixir's unique advantages make it attractive for certain machine learning scenarios, particularly those involving high-load systems and real-time data processing.

Model Training and Evaluation Example

# Data preparation  
train_images = train_images |> Nx.reshape({60000, 784}) |> Nx.divide(255.0)  
test_images = test_images |> Nx.reshape({10000, 784}) |> Nx.divide(255.0)  

# Creating data batches  
batches =  
  Stream.repeatedly(fn ->  
    indices = Nx.random_uniform(shape: {32}, min: 0, max: 60000) |> Nx.as_type(:s64)  
    x = Nx.take(train_images, indices)  
    y = Nx.take(train_labels, indices)  
    {x, y}  
  end)  

# Model definition with regularization and dropout  
model =  
  Axon.input("input", shape: {nil, 784})  
  |> Axon.dense(256, activation: :relu, kernel_regularizer: :l2)  
  |> Axon.dropout(rate: 0.4)  
  |> Axon.dense(128, activation: :relu)  
  |> Axon.dropout(rate: 0.3)  
  |> Axon.dense(10, activation: :softmax)  

# Training with early stopping and hyperparameter optimization  
trained_model_state =  
  model  
  |> Axon.Loop.trainer(:categorical_cross_entropy, Axon.Optimizers.adam(learning_rate: 0.001))  
  |> Axon.Loop.metric(:accuracy)  
  |> Axon.Loop.validate(test_data)  
  |> Axon.Loop.early_stopping("validation_loss", patience: 5)  
  |> Axon.Loop.run(batches, epochs: 20, iterations: 1000)  

# Model evaluation  
test_data = Stream.repeatedly(fn -> {test_images, test_labels} end) |> Stream.take(1)  
eval_results =  
  model  
  |> Axon.Loop.evaluator()  
  |> Axon.Loop.metric(:accuracy)  
  |> Axon.Loop.run(test_data, trained_model_state)

Comparison with Python Tools

Elixir for ML doesn't aim to replace Python completely but rather complements the existing ecosystem:

Criterion	Elixir (Nx/Axon)	Python (TensorFlow/PyTorch)
Ecosystem Maturity	Emerging	Mature
Performance	High (distributed systems)	GPU/TPU optimized
Hardware Support	CPU/GPU (via EXLA)	Extensive (CUDA, TPU, ROCm)
Concurrency	Built-in (BEAM VM)	Library-dependent
Available Models	Limited (Bumblebee)	Vast model repositories
Web Integration	Native (Phoenix LiveView)	Via Flask/FastAPI/Django
Deployment	Simple (Mix releases + OTP)	Complex (Docker/K8s)
Community	Growing	Massive
Documentation	High-quality (hexdocs)	Extensive but fragmented
Production Use	Erlang ecosystem (WhatsApp, Discord)	Industry leader (Google, Meta)

The best strategy often involves a hybrid approach: training models in Python and integrating them into Elixir systems for inference.

Advantages of Elixir for ML

Distributed Computing: BEAM enables easy distribution of training tasks across cluster nodes.
Real-time Processing: Thanks to actors and OTP, Elixir excels at streaming data processing (e.g., for IoT).
Reliability: Models can run in production with minimal downtime.

Limitations and Challenges

Despite rapid development, Elixir's ML ecosystem has some limitations:

Lack of certain specialized algorithms and optimization methods
Lower performance for very large models compared to optimized Python libraries
Limited TPU support
Fewer documentation and learning resources
Not all modern architectures (e.g., some transformers) have efficient implementations

Practical Applications

When to use Elixir for ML:

For integrating ML into existing Elixir/Phoenix applications
In systems requiring high fault tolerance and scalability
For real-time data processing and online learning
In distributed systems where concurrency matters

When Python is preferable:

For research and prototyping
When working with very large models (e.g., LLMs)
When specialized algorithms only available in Python are needed
With tight deadlines requiring ready-made solutions

The Future of Neural Networks in Elixir

The Elixir ML ecosystem is young but promising. Community efforts focus on:

Improving hardware acceleration integration (GPU/TPU)
Expanding pre-trained models in Axon
Enhancing data processing tools (Explorer, Scholar)

Conclusion

The ML ecosystem in Elixir is growing rapidly thanks to companies like Dashbit and developer contributions. For those wanting to dive deeper, we recommend:

From the Author

Thank you for reading! I hope this article helped you understand Elixir's potential in machine learning and inspired you to experiment with this powerful technology combination.

The Elixir ML ecosystem is evolving, and I welcome discussions about any questions, suggestions, or corrections. If you spot inaccuracies or have interesting additions—please share them in the comments. Constructive feedback is always valuable 😎

In Part 2, we'll build a complete ML project in Elixir, so stay tuned!

Elixir для Machine Learning. Часть 1 - Теория

Artyom Molchanov — Wed, 02 Apr 2025 13:35:52 +0000

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

В то время как Python доминирует в ML-ландшафте, Elixir находит применение в особых нишах: системы обработки данных в реальном времени (Bumblebee), сервисы инференса моделей (Nx.Serving) и распределенные системы машинного обучения. Компании, такие как DockYard и Dashbit, уже успешно внедряют ML-решения на Elixir в промышленной среде

Данная статья разделена на 2 части — Теория и Практика. В первой части мы рассмотрим основы машинного обучения, познакомимся с ключевыми понятиями и библиотеками, которые помогут создавать нейронные сети с использованием Elixir

Что такое машинное обучение и нейронные сети?

Машинное обучение (Machine Learning, ML) — это подход к созданию систем, которые могут обучаться на данных и улучшать свою производительность с опытом без явного программирования. Вместо написания конкретных инструкций для решения задачи, мы создаем модель, которая может адаптироваться и "учиться" на основе опыта

Нейронные сети — один из наиболее популярных методов машинного обучения, вдохновленный принципами работы человеческого мозга. Они представляют собой системы взаимосвязанных узлов (нейронов), организованных в слои:

Входной слой получает исходные данные (например, пиксели изображения)
Скрытые слои обрабатывают информацию, выявляя все более сложные паттерны
Выходной слой предоставляет итоговый результат (например, классификацию объекта)

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

Процесс обучения нейронной сети заключается в настройке этих весовых коэффициентов таким образом, чтобы сеть выдавала правильные результаты. Это происходит путем:

Подачи множества обучающих примеров
Вычисления ошибки между предсказаниями сети и фактическими значениями
Корректировки весов для минимизации этой ошибки с помощью алгоритма обратного распространения ошибки (backpropagation)

Ключевые концепции в машинном обучении

Модели и их типы

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

Линейные модели: Относительно простые модели, которые предполагают линейную зависимость между входными и выходными данными. Примеры: линейная регрессия, логистическая регрессия
Нейронные сети: Многослойные модели, которые могут выявлять сложные нелинейные зависимости. Применяются для задач компьютерного зрения, обработки естественного языка и других сложных проблем
Ансамбли моделей: Комбинации нескольких моделей для получения более точного результата. Примеры: случайные леса (Random Forests), градиентный бустинг (Gradient Boosting)

Тензоры и их роль в ML

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

Скаляр: Тензор ранга 0 (0-D). Пример: число 5
Вектор: Тензор ранга 1 (1-D). Пример: [1, 2, 3]
Матрица: Тензор ранга 2 (2-D). Пример: [[1, 2, 3], [4, 5, 6]]
Многомерный тензор: Тензор ранга 3+ (3-D и выше). Пример: [[[1, 2], [3, 4]], [[5, 6], [7, 8]]]

Тензоры используются для представления и обработки различных типов данных в ML:

Изображения (тензоры размерности 4: [batch_size, height, width, channels])
Тексты (последовательности векторов, представляющих слова или токены)
Временные ряды (последовательности наблюдений с течением времени)

Типы обучения

Обучение — процесс, при котором модель настраивает свои параметры на основе данных:

Обучение с учителем (Supervised Learning): Модель обучается на размеченных данных, где для каждого входного примера известен правильный ответ. Примеры задач: классификация изображений, прогнозирование цен, распознавание речи
Обучение без учителя (Unsupervised Learning): Модель обучается на неразмеченных данных, выявляя скрытые структуры и паттерны. Примеры задач: кластеризация, уменьшение размерности, обнаружение аномалий
Обучение с подкреплением (Reinforcement Learning): Модель обучается через взаимодействие с окружающей средой, получая награды или штрафы за свои действия. Применяется в робототехнике, играх, автономных системах

Гиперпараметры и их настройка

Гиперпараметры — это настройки модели, которые задаются до начала обучения и не изменяются в его процессе:

Архитектурные гиперпараметры: Количество слоёв в нейронной сети, количество нейронов в каждом слое, типы активационных функций
Параметры оптимизации: Скорость обучения (learning rate), размер батча (batch size), количество эпох обучения
Регуляризационные параметры: Коэффициенты L1/L2 регуляризации, параметр dropout для предотвращения переобучения

Настройка гиперпараметров обычно выполняется с помощью методов, таких как поиск по сетке (grid search), случайный поиск (random search) или байесовская оптимизация

Метрики оценки моделей

Метрики — это количественные показатели, которые используются для оценки качества работы модели:

Для задач классификации:
- Точность (Accuracy): Доля правильных предсказаний среди всех предсказаний
- Точность и полнота (Precision & Recall): Показатели, отражающие баланс между ложноположительными и ложноотрицательными результатами
- F1-мера: Гармоническое среднее между точностью и полнотой
- ROC-AUC: Площадь под ROC-кривой, отражающая способность модели различать классы
Для задач регрессии:
- Среднеквадратичная ошибка (MSE): Среднее значение квадратов разностей между предсказанными и фактическими значениями
- Средняя абсолютная ошибка (MAE): Среднее значение абсолютных разностей между предсказанными и фактическими значениями
- Коэффициент детерминации (R²): Показывает, насколько хорошо модель объясняет вариацию данных

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

Теперь, когда мы рассмотрели ключевые концепции машинного обучения, давайте перейдем к инструментам, которые делают возможным применение этих концепций в экосистеме Elixir

Инструменты Elixir для машинного обучения

Экосистема машинного обучения в Elixir быстро развивается, предлагая все более мощные и удобные инструменты для разработчиков. Рассмотрим ключевые библиотеки, которые делают возможным применение ML на платформе BEAM

Numerical Elixir (Nx): Фундамент для вычислений

Nx — это основа всей ML-экосистемы Elixir, разработанная командой Dashbit под руководством Жозе Валима (создателя Elixir). Эта библиотека предоставляет высокоэффективные числовые вычисления и поддержку многомерных тензоров, что критически важно для машинного обучения

Ключевые возможности Nx:

Тензорные операции: Полный набор функций для манипуляции многомерными массивами данных
Численная стабильность: Высокая точность вычислений с контролем численных ошибок
Компиляция вычислений: Преобразование кода Elixir в оптимизированный машинный код
Автоматическое дифференцирование: Необходимое для алгоритмов обратного распространения ошибки

Особенно мощной особенностью Nx является система defn (определяемых числовых функций), которая позволяет компилировать вычисления в эффективный низкоуровневый код:

defmodule MathOps do
  import Nx.Defn

  defn multiply_and_add(a, b, c) do
    a * b + c
  end
end

# Использование
x = Nx.tensor([1, 2, 3])
y = Nx.tensor([4, 5, 6])
z = Nx.tensor([7, 8, 9])
MathOps.multiply_and_add(x, y, z)
# Результат: Nx.tensor([11, 18, 27])

Поддерживаемые бэкенды Nx:

Nx работает через систему бэкендов, которые определяют, где и как будут выполняться вычисления:

EXLA: Интеграция с XLA (Accelerated Linear Algebra) от Google, обеспечивающая компиляцию для CPU, GPU и TPU
Torchx: Соединение с PyTorch, использующее его оптимизированные CUDA-операции
ONNX: Поддержка Open Neural Network Exchange для совместимости с широким спектром моделей
BinaryBackend: Нативная реализация на Elixir, не требующая внешних зависимостей

Выбор бэкенда зависит от задачи и доступного оборудования:

# Глобальное использование EXLA-бэкенда
Nx.global_default_backend(EXLA.Backend)

# Использование PyTorch для конкретной операции
Nx.backend_transfer(tensor, {Torchx.Backend, device: :cuda})

Axon: Нейронные сети с функциональным подходом

Axon — это высокоуровневый фреймворк для определения, обучения и оценки нейронных сетей, построенный поверх Nx. Главная особенность Axon — функциональный дизайн, идеально соответствующий философии Elixir

Особенности Axon:

Декларативное определение моделей: Понятный пайплайн-подход к созданию архитектур
Встроенные оптимизаторы: Реализации Adam, SGD, RMSProp и других алгоритмов
Функции потерь: Широкий набор для различных задач (MSE, кросс-энтропия и др.)
Управление обучением: Инструменты для раннего останова, валидации, обратных вызовов

Пример создания и обучения модели классификации:

# Определение модели
model =
  Axon.input("input", shape: {nil, 784})
  |> Axon.dense(512)
  |> Axon.relu()
  |> Axon.dense(10)
  |> Axon.softmax()

# Компиляция и обучение
trained_model =
  model
  |> Axon.Loop.trainer(:categorical_cross_entropy, :adam)
  |> Axon.Loop.metric(:accuracy)
  |> Axon.Loop.run(train_data, epochs: 5, compiler: EXLA)

Расширенные возможности Axon:

Axon поддерживает широкий спектр слоев и архитектур:

Сверточные слои: Для задач компьютерного зрения (Axon.conv)
Рекуррентные сети: LSTM, GRU для последовательных данных
Трансформеры: Внимание, мультиголовое внимание для NLP
Нормализация: BatchNorm, LayerNorm для стабилизации обучения
Регуляризация: Dropout, L1/L2 для борьбы с переобучением

Пример сверточной сети для классификации изображений:

model =
  Axon.input("input", shape: {nil, 1, 28, 28})
  |> Axon.conv(32, kernel_size: 3, padding: :same)
  |> Axon.relu()
  |> Axon.max_pool(kernel_size: 2)
  |> Axon.conv(64, kernel_size: 3, padding: :same)
  |> Axon.relu()
  |> Axon.max_pool(kernel_size: 2)
  |> Axon.flatten()
  |> Axon.dense(128)
  |> Axon.relu()
  |> Axon.dense(10)
  |> Axon.softmax()

Explorer: Обработка и подготовка данных

Explorer — библиотека для работы с табличными данными, вдохновленная Pandas из Python. Она тесно интегрируется с Nx, позволяя легко преобразовывать данные в тензоры

Ключевые возможности Explorer:

DataFrame API: Мощный интерфейс для манипуляций с данными
Фильтрация и группировка: Эффективная работа с большими наборами данных
Загрузка/сохранение: Поддержка CSV, Parquet, JSON и других форматов
Визуализация: Интеграция с Vega-Lite для создания диаграмм

Пример работы с данными:

# Загрузка и обработка данных
df = Explorer.DataFrame.from_csv!("titanic.csv")
  |> Explorer.DataFrame.filter(age > 18)
  |> Explorer.DataFrame.select(["survived", "age", "sex", "fare"])
  |> Explorer.DataFrame.mutate(fare_category: apply(fare, fn fare -> 
    cond do
      fare < 20 -> "low"
      fare < 50 -> "medium"
      true -> "high"
    end
  end))

#### Преобразование в тензоры для ML
features = Explorer.DataFrame.to_nx(df, ["age", "sex", "fare"])
labels = Explorer.DataFrame.to_nx(df, ["survived"])

Bumblebee: Готовые модели для практического применения

Bumblebee — это библиотека, предоставляющая предобученные модели и инструменты для их использования. Bumblebee значительно упрощает работу с современными моделями без необходимости обучать их с нуля

Ключевые возможности:

Предобученные модели: BERT, GPT-2, ResNet, CLIP, Stable Diffusion и другие
Встроенные пайплайны: Готовые решения для типовых задач
Интеграция с Hugging Face: Доступ к тысячам моделей
Оптимизированный инференс: Эффективное выполнение на различном оборудовании

Пример использования для анализа тональности текста:

{:ok, model_info} = Bumblebee.load_model({:hf, "distilbert-base-uncased-finetuned-sst-2-english"})
{:ok, tokenizer} = Bumblebee.load_tokenizer({:hf, "distilbert-base-uncased"})

serving = Bumblebee.Text.sentiment(model_info, tokenizer, compile: [batch_size: 1])

Nx.Serving.run(serving, "I love Elixir, it's an amazing language!")
# => %{predictions: [%{label: "POSITIVE", score: 0.998}]}

Nx.Serving: Развертывание моделей в продакшене

Nx.Serving — инструмент для эффективного развертывания ML-моделей в качестве сервисов. Он обеспечивает:

Батчинг запросов: Автоматическое группирование для эффективного выполнения
Очереди и приоритеты: Управление нагрузкой и распределение ресурсов
Горячая замена: Обновление моделей без простоя
Мониторинг: Отслеживание производительности и использования ресурсов

Пример создания сервиса для распознавания изображений:

model_info = Bumblebee.load_model({:hf, "microsoft/resnet-50"})
featurizer = Bumblebee.load_featurizer({:hf, "microsoft/resnet-50"})

serving =
  Bumblebee.Vision.image_classification(
    model_info,
    featurizer,
    compile: [batch_size: 8],  # Динамический батчинг
    defn_options: [compiler: EXLA]  # Использование GPU
  )

# Запуск как процесса OTP
{:ok, pid} = Nx.Serving.start_link(serving, name: ImageClassifier)

# Использование
{:ok, image} = Image.from_file("cat.jpg")
Nx.Serving.batched_run(ImageClassifier, image)

LiveBook: Интерактивная разработка и эксперименты

LiveBook — это интерактивная среда для разработки и документирования кода Elixir, идеально подходящая для ML-экспериментов. Она предоставляет:

Jupyter-подобный интерфейс: Интерактивные ячейки кода
Встроенная визуализация: Диаграммы, графики, таблицы
Интеграция с ML-библиотеками: Специальные виджеты для Nx, Axon, Explorer
Совместная работа: Возможность делиться ноутбуками и работать над ними вместе
Выполнение на GPU: Поддержка аппаратного ускорения

LiveBook существенно упрощает обучение, экспериментирование и документирование ML-проектов на Elixir:

# Пример ячейки LiveBook
Mix.install([
  {:nx, "~> 0.5"},
  {:axon, "~> 0.5"},
  {:explorer, "~> 0.5"},
  {:kino, "~> 0.8"}
])

### Интерактивный ввод гиперпараметров
form = Kino.Control.form(
  [
    learning_rate: Kino.Input.text("Learning rate", default: "0.001"),
    epochs: Kino.Input.range(1..100, default: 10)
  ],
  submit: "Train model"
)

Scholar: Традиционные алгоритмы машинного обучения

Scholar расширяет экосистему Elixir ML классическими алгоритмами, которые часто бывают более подходящими для определенных задач, чем глубокое обучение:

Линейные модели: Регрессия, SVM, логистическая регрессия
Деревья решений: Одиночные деревья и ансамбли
Кластеризация: K-means, DBSCAN
Понижение размерности: PCA, t-SNE
Статистические методы: Байесовские модели, оценка плотности

Пример использования линейной регрессии:

import Scholar.Linear.LinearRegression
import Nx.Defn

# Подготовка данных
x = Nx.tensor([[1.0, 1.0], [1.0, 2.0], [2.0, 2.0], [2.0, 3.0]])
y = Nx.tensor([6.0, 8.0, 9.0, 11.0])

# Обучение модели
model = fit(x, y)

# Предсказание
predict(model, Nx.tensor([[3.0, 5.0]]))
# => #Nx.Tensor
#  f32[1]
#  [17.0]
# >

Практическое применение: Интеграция с Phoenix

Отдельно стоит отметить, насколько органично ML-модели интегрируются с веб-фреймворком Phoenix, создавая мощные интеллектуальные веб-приложения:

defmodule MyAppWeb.MLController do
  use MyAppWeb, :controller
  alias Nx.Serving

  # Инициализация модели при старте приложения
  @serving Bumblebee.Text.sentiment(model_info, tokenizer, compile: [batch_size: 4])
  Serving.start_link(@serving, name: SentimentAnalyzer)

  def analyze(conn, %{"text" => text}) do
    # Асинхронный анализ
    Task.async(fn ->
      Serving.batched_run(SentimentAnalyzer, text)
    end)
    |> Task.await()
    |> case do
      %{predictions: [%{label: label, score: score}]} ->
        json(conn, %{sentiment: label, confidence: score})
      _ ->
        conn
        |> put_status(422)
        |> json(%{error: "Analysis failed"})
    end
  end
end

Такая интеграция позволяет легко создавать API для анализа текста, классификации изображений, рекомендательных систем и многих других ML-приложений, используя все преимущества BEAM для горизонтального масштабирования и высокой доступности

Экосистема ML в Elixir предлагает сбалансированное сочетание высокоуровневых инструментов и низкоуровневого контроля, позволяя выбрать подходящий уровень абстракции для конкретной задачи. Хотя она еще не так обширна, как Python-экосистема, уникальные преимущества BEAM делают Elixir привлекательным выбором для определенных сценариев машинного обучения, особенно связанных с высоконагруженными системами и обработкой данных в реальном времени

Пример кода для обучения и оценки модели

# Подготовка данных
train_images = train_images |> Nx.reshape({60000, 784}) |> Nx.divide(255.0)
test_images = test_images |> Nx.reshape({10000, 784}) |> Nx.divide(255.0)

# Создание батчей данных
batches =
  Stream.repeatedly(fn ->
    indices = Nx.random_uniform(shape: {32}, min: 0, max: 60000) |> Nx.as_type(:s64)
    x = Nx.take(train_images, indices)
    y = Nx.take(train_labels, indices)
    {x, y}
  end)

# Определение модели с регуляризацией и дропаутом
model =
  Axon.input("input", shape: {nil, 784})
  |> Axon.dense(256, activation: :relu, kernel_regularizer: :l2)
  |> Axon.dropout(rate: 0.4)
  |> Axon.dense(128, activation: :relu)
  |> Axon.dropout(rate: 0.3)
  |> Axon.dense(10, activation: :softmax)

# Обучение с ранним остановом и оптимизацией гиперпараметров
trained_model_state =
  model
  |> Axon.Loop.trainer(:categorical_cross_entropy, Axon.Optimizers.adam(learning_rate: 0.001))
  |> Axon.Loop.metric(:accuracy)
  |> Axon.Loop.validate(test_data)
  |> Axon.Loop.early_stopping("validation_loss", patience: 5)
  |> Axon.Loop.run(batches, epochs: 20, iterations: 1000)

# Оценка модели
test_data = Stream.repeatedly(fn -> {test_images, test_labels} end) |> Stream.take(1)
eval_results =
  model
  |> Axon.Loop.evaluator()
  |> Axon.Loop.metric(:accuracy)
  |> Axon.Loop.run(test_data, trained_model_state)

Сравнение с Python-инструментами

Elixir для ML не стремится полностью заменить Python, а скорее дополняет существующую экосистему:

Критерий	Elixir (Nx/Axon)	Python (TensorFlow/PyTorch)
Зрелость экосистемы	Развивающаяся	Зрелая
Производительность	Высокая (распределенные системы)	Оптимизирована под GPU/TPU
Поддержка железа	CPU/GPU (через EXLA)	Широкая (CUDA, TPU, ROCm)
Параллелизм	Встроенный (BEAM VM)	Зависит от библиотек
Доступные модели	Ограниченный набор (Bumblebee)	Обширные репозитории моделей
Интеграция с веб	Нативная (Phoenix LiveView)	Через Flask/FastAPI/Django
Развертывание	Простое (микс релизы + OTP)	Комплексное (Docker/K8s)
Сообщество	Растущее	Огромное
Документация	Качественная (hexdocs)	Обширная (но фрагментированная)
Использование в продакшене	Erlang-экосистема (WhatsApp, Discord)	Лидер индустрии (Google, Meta)

Лучшая стратегия часто заключается в использовании гибридного подхода: обучение моделей на Python и их интеграция в Elixir-системы для инференса

Преимущества Elixir в ML

Распределённые вычисления. BEAM позволяет легко распределять задачи обучения между узлами кластера
Обработка в реальном времени. Благодаря акторам и OTP, Elixir эффективен для потоковой обработки данных (например, в IoT)
Надёжность. Модели могут работать в продакшене с минимальным временем простоя

Ограничения и вызовы

Несмотря на быстрое развитие, экосистема ML в Elixir имеет ряд ограничений:

Отсутствие некоторых специализированных алгоритмов и методов оптимизации
Меньшая производительность для очень больших моделей по сравнению с оптимизированными Python-библиотеками
Ограниченная поддержка TPU
Меньше документации и обучающих материалов
Не все современные архитектуры (например, некоторые виды трансформеров) имеют эффективные реализации

Практические применения

Когда стоит использовать Elixir для ML:

Для интеграции ML в существующие Elixir/Phoenix-приложения
В системах, требующих высокой отказоустойчивости и масштабируемости
Для обработки данных в реальном времени и онлайн-обучения
В распределенных системах, где важен параллелизм

Когда лучше использовать Python:

Для исследовательской работы и прототипирования
При работе с очень большими моделями (например, большими языковыми моделями)
Когда требуются специализированные алгоритмы, доступные только в Python-библиотеках
При ограниченном времени на разработку и необходимости использовать готовые решения

Будущее нейросетей на Elixir

Экосистема Elixir для ML ещё молода, но перспективна. Усилия сообщества направлены на:

Улучшение интеграции с аппаратным ускорением (GPU/TPU)
Расширение списка готовых моделей в Axon
Развитие инструментов для обработки данных (Explorer, Scholar)

Заключение

Экосистема ML в Elixir активно развивается благодаря усилиям компаний, таких как Dashbit, и сообщества разработчиков. Для тех, кто хочет глубже погрузиться в тему, рекомендуем следующие ресурсы:

От автора

Благодарю вас за внимание к этой статье! Надеюсь, она помогла вам лучше понять возможности Elixir в сфере машинного обучения и вдохновила на собственные эксперименты с этой мощной комбинацией технологий =)

Экосистема ML в Elixir активно развивается, и я буду рад обсудить любые вопросы, предложения или замечания. Если вы обнаружили неточности в материале или у вас есть интересные дополнения — пожалуйста, напишите об этом в комментариях. Конструктивная обратная связь всегда ценна 😎

Во второй части статьи мы перейдем к практике и создадим полноценный ML-проект на Elixir, так что не пропустите продолжение!

Forem: Artyom Molchanov

Ash Framework: Introduction

📖 Preface

🚀 What is Ash?

🔑 Key Abstractions in Ash

🧩 What is a Resource?

Resource — The Heart of Ash

Complete Example of a Modern Resource

Main Sections of Resource

Key Features of Resource

When to Create a New Resource?

🛠️ More About Actions

Five Types of Actions

Complete Example of All Action Types

How to Call Actions

Main Capabilities of Actions

1. argument — Input Parameters

2. accept — Which Attributes Can Be Changed

3. change — Data Transformations

4. prepare — Query Preparation (mainly for read)

5. Hooks (before/after)

6. transaction? — Transaction Management

7. pipe_through — Reusing Logic

Why Actions Are Awesome?

Comparison with Classic Elixir/Phoenix

🏢 What is a Domain?

Three Main Goals of Domain

How Domain Looks in Practice

Why Do You Need Domain?

Best Practices When Working with Domains

Comparison: Domain vs Resource

Why Domain Is Especially Useful?

⚔️ Ash + Phoenix vs Ecto + Phoenix

What to Choose in 2026?

😴 Conclusion

🙏 From the Author

Ash Framework: Знакомство

📖 Предисловие

🚀 Что такое Ash?

🔑 Ключевые абстракции Ash

🧩 Что такое Ресурс?

Resource — сердце Ash

Полный пример современного Resource

Основные разделы Resource

Ключевые особенности Resource

Когда создавать новый Resource?

🛠️ Подробнее об Actions (Действиях)

Пять типов Actions

Полный пример всех типов Actions

Как вызывать Actions

Основные возможности Actions

1. argument — входные параметры

2. accept — какие атрибуты можно менять

3. change — трансформации данных

4. prepare — подготовка запроса (в основном для read)

5. Хуки (before/after)

6. transaction? — управление транзакцией

7. pipe_through — переиспользование логики

Почему Actions — это круто?

Сравнение с классическим Elixir/Phoenix

🏢 Что такое Domain (Домены)?

Три главные цели Domain

Как выглядит Domain на практике

Зачем нужен Domain?

Лучшие практики при работе с доменом

Сравнение: Domain vs Resource

Почему Domain особенно полезен?

⚔️ Ash + Phoenix vs Ecto + Phoenix

Что стоит выбрать в 2026 году?

😴 В заключение

🥴 От автора

[Boost]

AD9833 DDS Generator Board

[Boost]

The Internet Is Getting Quieter - Who Will Feed the Next Generation of AI?

BEAM: In Plain English

What Is a Virtual Machine? 🤔

Why Are Virtual Machines Needed? 🌟

Popular Virtual Machines: Who's Who? 🦸‍♂️

Deeper Look Into BEAM 🌌

1. `argument` — Input Parameters

2. `accept` — Which Attributes Can Be Changed

3. `change` — Data Transformations

4. `prepare` — Query Preparation (mainly for `read`)

6. `transaction?` — Transaction Management

7. `pipe_through` — Reusing Logic

1. `argument` — входные параметры

2. `accept` — какие атрибуты можно менять

3. `change` — трансформации данных

4. `prepare` — подготовка запроса (в основном для `read`)

6. `transaction?` — управление транзакцией

7. `pipe_through` — переиспользование логики