DEV Community: Cherry Ramatis

Recently, I read a particular blog post by yobibyte about a no-plugins approach to Neovim configuration, which stuck with me. I started to think more and more about how much stuff I really need for my config to suit my needs. Personally, the main reason why I resonate so much with a particular family of editors (Vim, Nvim, Kakoune, Emacs, etc.) is the ability to add as much stuff as you want, but at the same time the opportunity to remove as much bloat as possible—a little controversial, but if you think about it, it's the best scenario for customizability. I remember watching a video about the concept of a PDE coined by a Neovim contributor called teej_dv, and it really stuck with me. These types of editors are more like an environment than just a product with a single goal.

Well, this is the exact situation I'm currently in, trying to experiment with native functions from Neovim and writing tiny wrappers around them instead of using plugins that recreate the whole UX. I hope you find this particular "wrapper" useful for your workflow. :)

First things first, it's important to point out that I'm using neovim nightly, this is important because we need two particular patches to make all this work properly, which is this the vim patch adding wildtrigger() function for cmdline completion (neovim equivalent) and the vim patch adding findfunc as a option (neovim equivalent). If at the time you're reading this post those patches are already available at stable version, you don't need to worry with building from source.

For the ones with a practical sense, this is the whole module I have at plugin/cmdline.lua for you to copy and try for yourself. Throughout this blog post, we'll break up piece by piece how it works.

if vim.fn.executable "rg" == 1 then
    function _G.RgFindFiles(cmdarg, _cmdcomplete)
        local fnames = vim.fn.systemlist('rg --files --hidden --color=never --glob="!.git"')
        if #cmdarg == 0 then
            return fnames
        else
            return vim.fn.matchfuzzy(fnames, cmdarg)
        end
    end

    vim.o.findfunc = 'v:lua.RgFindFiles'
end

local function is_cmdline_type_find()
    local cmdline_cmd = vim.fn.split(vim.fn.getcmdline(), ' ')[1]

    return cmdline_cmd == 'find' or cmdline_cmd == 'fin'
end

vim.api.nvim_create_autocmd({ 'CmdlineChanged', 'CmdlineLeave' }, {
    pattern = { '*' },
    group = vim.api.nvim_create_augroup('CmdlineAutocompletion', { clear = true }),
    callback = function(ev)
        local function should_enable_autocomplete()
            local cmdline_cmd = vim.fn.split(vim.fn.getcmdline(), ' ')[1]

            return is_cmdline_type_find() or cmdline_cmd == 'help' or cmdline_cmd == 'h'
        end

        if ev.event == 'CmdlineChanged' and should_enable_autocomplete() then
            vim.opt.wildmode = 'noselect:lastused,full'
            vim.fn.wildtrigger()
        end

        if ev.event == 'CmdlineLeave' then
            vim.opt.wildmode = 'full'
        end
    end
})

vim.keymap.set('n', '<leader>f', ':find<space>', { desc = 'Fuzzy find' })

vim.keymap.set('c', '<m-e>', '<home><s-right><c-w>edit<end>', { desc = 'Change command to :edit' })
vim.keymap.set('c', '<m-d>', function()
    if not is_cmdline_type_find() then
        vim.notify('This binding should be used with :find', vim.log.levels.ERROR)
        return
    end

    local cmdline_arg = vim.fn.split(vim.fn.getcmdline(), ' ')[2]

    if vim.uv.fs_realpath(vim.fn.expand(cmdline_arg)) == nil then
        vim.notify('The second argument should be a valid path', vim.log.levels.ERROR)
        return
    end

    local keys = vim.api.nvim_replace_termcodes(
        '<C-U>edit ' .. vim.fs.dirname(cmdline_arg),
        true,
        true,
        true
    )
    vim.fn.feedkeys(keys, 'c')
end, { desc = 'Edit the dir for the path' })

vim.keymap.set('c', '<c-v>', '<home><s-right><c-w>vs<end>', { desc = 'Change command to :vs' })
vim.keymap.set('c', '<c-s>', '<home><s-right><c-w>sp<end>', { desc = 'Change command to :sp' })
vim.keymap.set('c', '<c-t>', '<home><s-right><c-w>tabe<end>', { desc = 'Change command to :tabe' })

And here is a demo showing off all the features available:

Disclaimer: The screenkey plugin here is a bit laggy so consider referencing the keybinds with the code block above if something was confusing.

Breaking up piece by piece

OK! Time to dive into this module. The first feature that honestly made all this even possible is the simplest to explain: the findfunc option. This patch was merged into Neovim in November 2024 from a Vim patch and introduced the possibility of customizing how the editor searched files using the :find cmd.

Historically, Vim users that wanted a more native file finder were using a rather hacky trick that consisted of configuring the path option with a glob pattern like this: set path+=**. By adding this, the :find command could expand to the whole project structure to find a file. The problem? Performance: It's quite slow using the GNU find binaries in large codebases.

But with findfunc, we can make this command use faster binaries like fd, rg or even using our favorite VCS like git ls-files to increase the initial performance hit of loading the files. Basically, we have a functional file finder now! Yay!

All this is nice, but it's missing one important piece to the function: fuzzy matching. You know, that thing that makes the telescope plugin really shine, that allows you to type roughly the file name and still get the correct matches? We can achieve this by using the matchfuzzy to further filter the options as the user types.

This sums up our first function:

function _G.RgFindFiles(cmdarg, _cmdcomplete)
    local fnames = vim.fn.systemlist('rg --files --hidden --color=never --glob="!.git"')
    if #cmdarg == 0 then
        return fnames
    else
        return vim.fn.matchfuzzy(fnames, cmdarg)
    end
end

vim.o.findfunc = 'v:lua.RgFindFiles'

As you can see, the cmdarg is the substring typed by the user (it's nil when the user didn't type anything). For this function, we separate into returning the whole list of files when the user hasn't typed anything yet and returning the fuzzy matched list according to the substring provided. The function will be called every time the user manually presses the <tab> key, and all the details regarding the limit of items shown and navigation are dealt with by the wildmenu option (you can find more about it with :h wildmenu)

Nice! We now have tab-completed fuzzy finding; let's spice things up with ✨ autocompletion ✨. I'm not a particular fan of autocompletion when I'm typing on a buffer, but it certainly fits perfectly when filtering file paths.

For this to be possible comes our second patch that introduced the wildtrigger() function. It is quite simple in theory: it triggers completion programmatically when on the cmdline, it works for commands like / :s and, of course, :find. When combined with the autocmd event CmdlineChanged we can programmatically trigger the completion every time we type a character into the cmdline, cool, right?

The simplest version of this behavior can be declared as follows:

vim.api.nvim_create_autocmd({ 'CmdlineChanged' }, {
    pattern = { '*' },
    group = vim.api.nvim_create_augroup('CmdlineAutocompletion', { clear = true }),
    callback = function(ev)
        vim.opt.wildmenu = true
        vim.opt.wildmode = 'noselect:lastused,full'
        vim.fn.wildtrigger()
    end
})

You can move the wildmenu and wildmode configuration outside the autocmd without any problems, we're just containing more in favor of control and simplicity.

Together with the wildtrigger function being called on every change, we have a neat setting being placed here: the wildmode. This option is important because it allows us to not immediately insert the first option when the completion popup appears; it's similar to what we set in completeopt to configure buffer autocompletion frameworks like nvim-cmp.

For context, let's take a look into the full description for this option from the help pages:

"full"              Complete the next full match.  Cycles through all
                    matches, returning to the original input after the
                    last match.  If 'wildmenu' is enabled, it will be
                    shown.

"noselect:lastused" Do not preselect the first item in 'wildmenu'
                    if it is active.  When completing buffers,
                    sort them by most recently used (excluding the
                    current buffer).

This is already our full feature of fuzzy finding with autocomplete! Further on in this article, we'll write keymaps around the cmdline mode to improve the UX, shall we? :)

First let's constrain this autocomplete to work on specific commands. This is particularly useful to me because I don't want autocompletion in commands like :edit, just on the ones important to fuzzy finding (in this case, :help and :find).

vim.api.nvim_create_autocmd({ 'CmdlineChanged', 'CmdlineLeave' }, {
    pattern = { '*' },
    group = vim.api.nvim_create_augroup('CmdlineAutocompletion', { clear = true }),
    callback = function(ev)
        local function should_enable_autocomplete()
            local cmdline_cmd = vim.fn.split(vim.fn.getcmdline(), ' ')[1]

            -- NOTE: Here your can add any other variant that you commonly type to abbreviate the command. :)
            return cmdline_cmd == 'find' or cmdline_cmd == 'fin' or cmdline_cmd == 'help' or cmdline_cmd == 'h'
        end

        if ev.event == 'CmdlineChanged' and should_enable_autocomplete() then
            vim.opt.wildmode = 'noselect:lastused,full'
            vim.fn.wildtrigger()
        end

        if ev.event == 'CmdlineLeave' then
            vim.opt.wildmode = 'full'
        end
    end
})

There are two main aspects of this version, the cleanup and the cmdline check:

cleanup :: On this version, we're listening to an additional event CmdlineLeave which we use to reset the wildmode option to the default value. This is important to not affect further commands on the cmdline. To do that, we take advantage of the ev parameter passed to the callback; with it we can check the .event and perform different actions.
cmdline check :: With the function vim.fn.getcmdline() we get the whole content of the cmdline typed so far as a string, considering that it is just a matter of string parsing to get the parts we want. To keep it simple, we're just splitting on spaces and checking the first word (the command).

Great! Our current version has a controlled autocompletion based on the command and a fuzzy finding method attached to it. What else is needed? Now we'll add the convenient strategies implied by plugin fuzzy finders to open the selection on splits and other cool additions that worked for me personally.

I need to be honest here; some of these keymaps I got the idea from Emacs (no judgments), and it suited so well with this finder. Some of them are quite simple, and we'll start off with them!

vim.keymap.set('c', '<m-e>', '<home><s-right><c-w>edit<end>', { desc = 'Change command to :edit' })
vim.keymap.set('c', '<c-v>', '<home><s-right><c-w>vs<end>', { desc = 'Change command to :vs' })
vim.keymap.set('c', '<c-s>', '<home><s-right><c-w>sp<end>', { desc = 'Change command to :sp' })
vim.keymap.set('c', '<c-t>', '<home><s-right><c-w>tabe<end>', { desc = 'Change command to :tabe })

Quite simple, right? All of them do the same thing: they change the command to achieve different actions like opening on a split, a tab, etc. Let's break the syntax briefly:

<home><s-right><c-w> :: This sequence first sends the cursor to the beginning of the line (<home>), then navigates one word to the right (<s-right> or shift+right) and finally deletes the word from right to left (<c-w> or ctrl+w). Leaving the cmdline without the command, for example, :<<cursor_here>> plugin/cmdline.lua
word + <end> :: Here it is quite straightforward; the word changes from each command, and the <end> sends the cursor to the end of the line, so you can continue typing or press enter to confirm the command.

Got it? These bindings already bring up the functionalities provided by common fuzzy finders, but let's go a little further with an additional keymap: manipulate the current path to get the directory instead. The purpose is to easily open the directory for a file to move/copy/delete something.

vim.keymap.set('c', '<m-d>', function()
    local cmdline = vim.fn.split(vim.fn.getcmdline(), ' ')

    local cmdline_cmd = cmdline[1]

    if not (cmdline_cmd == 'find' or cmdline_cmd == 'fin') then
        vim.notify('This binding should be used with :find', vim.log.levels.ERROR)
        return
    end

    local cmdline_arg = cmdline[2]

    if vim.uv.fs_realpath(vim.fn.expand(cmdline_arg)) == nil then
        vim.notify('The second argument should be a valid path', vim.log.levels.ERROR)
        return
    end

    local keys = vim.api.nvim_replace_termcodes(
        '<C-U>edit ' .. vim.fs.dirname(cmdline_arg),
        true,
        true,
        true
    )
    vim.fn.feedkeys(keys, 'c')
end, { desc = 'Edit the dir for the path' })

The initial part parses the whole cmdline string (like we saw earlier about the usage of vim.fn.getcmdline()) to check if the current command is :find and if the second argument is a valid path. We just want to process these cases.

The cmdline manipulation on this part is a little trickier because instead of just outputting the special syntax like the previous keymaps, we need to do it programmatically. For this to be possible, we need two important functions: vim.api.nvim_replace_termcodes and vim.fn.feedkeys.

vim.api.nvim_replace_termcodes :: This function transforms special syntax like <c-u> into a version commonly used in shells; it mostly transforms these modifiers into escape sequences like ^\U for ctrl+u.
vim.fn.feedkeys :: This function passes the sequence of keys and tries to mimic them into the mode specified. For our case it's mimicking the key sequence with the cmdline mode 'c'. It emulates what would happen if you had typed that sequence manually.

Another important function is the vim.fs.dirname one, this function receive a path as argument and return the path to the parent directory of it, like the following:
vim.fs.dirname("plugin/cmdline.lua") -- "plugin"`
vim.fs.dirname("/home/user/.config/nvim/after/plugin/test.lua") -- "/home/user/.config/nvim/after/plugin/"`

Having explained these functions, we can sum up the behavior of the binding like the following: For the :find command, by pressing option+d or alt+d we replace the path with the parent directory version of it, allowing you to open your file browser of choice.

The <c-u> or ctrl+u triggered from the function delete the content of the whole line.

Final thoughts

I hope some of this is useful for you reading it! Either by knowing a new function or some interesting behavior that you didn't know about nvim, the main goal with these explorations is to know more about the editor we all use every day. Feel free to reach out so we can talk more about this topic. :) May the Force be with you. 🍒.

[Boost]

Cherry Ramatis — Tue, 03 Jun 2025 01:45:15 +0000

Stefany Brauns for Elas Falam Tech

Jun 2 '25

[pt-br] Você sabe o que é o ambiente em produção (prd) e desenvolvimento? (dev)

#beginners #learning #braziliandevs

129

2 min read

[Boost]

Cherry Ramatis — Thu, 20 Mar 2025 19:41:05 +0000

How I learn any type of new technology (As a Senior Developer)

Daniel Reis ・ Mar 20 '25

#programming #beginners #productivity #learning

I'm looking for a FullStack Software Developer Role

Cherry Ramatis — Tue, 25 Jun 2024 17:09:10 +0000

Hey y'all, hope you've been doing and feeling great! My name is Cherry Ramatis, and I'm currently looking for opportunities as a FullStack software developer.

I'm passionate about learning new things and being an active figure in the community to democratize knowledge as I find this the key to being a better professional and knowing cool people at the same time (win-win situation). I'm managing to do that by attending meetups, presenting talks, giving mentorship to junior and mid-level devs, producing friendly yet resourceful articles, and overall being an accessible and helpful figure with anyone.

On the personal side I have three beautiful dogs that I adore to walk by the beach and I love hanging out to karaoke pubs with my friends (great opportunity for a cool happy hour 👀)

A little bit to know me

Name: Cherry Ramatis
Currently living in: São Paulo Brazil
Technologies that I actively work with professionally:
- Typescript/Javascript
- React
- Nextjs
- Angular
- Nestjs
- Docker
- Github Actions
- PostgreSQL
- MongoDB
Technologies that I would love to work with:
- Ruby
- Ruby on Rails
- Elixir
- Phoenix
Time coding in total: About 10 years
Time coding professionally: Currently in my 6 year
Number of talks performed both online and in person:
- 3 online talks presented at the He4rt Developers community
- 1 in person talk presented at the ElixirDays
Number of published articles: Currently at 21 articles published with around 67k views and 11k reached people

Achievements that I'm proud of

Participation for a brazilian podcast "Elixir em Foco": https://www.youtube.com/watch?v=zYl6ec4G4k8
Mention as one of the top 7 authors of 2023 by dev.to: https://dev.to/devteam/top-7s-top-authors-of-the-year-120m
Open source contribution to a big database company: https://cloud-getting-started.scylladb.com/stable/build-with-ruby

My favorite projects

Regexer - A compiler from a single line language to regex: https://github.com/cherryramatisdev/regexer
Modular architecture for HTTP Server with dependency injection using Ruby: https://github.com/cherryramatisdev/api-with-dry-ruby
A compiler from a pseudo language to a valid byte code BEAM file in rust and elixir: https://github.com/cherryramatisdev/beam_studies
A experiment with ruby to transform exceptions into Result monads: https://github.com/cherryramatisdev/monadic-exceptions

How you can reach me

Linkedin: https://www.linkedin.com/in/cherryramatis/
Twitter: https://x.com/cherryramatis
Dev.to: https://dev.to/cherryramatis

BEAM VM The good, the bad and the ugly

Cherry Ramatis — Mon, 20 May 2024 22:14:04 +0000

A BEAM é uma VM que está sendo muito falada ultimamente com o advento de novas tecnologias como gleam e riot a utilizando como target de compilação ou mesmo recriando algumas de suas funcionalidades. A parte legal é que essa VM é beeeem antiga, sendo criada pela Ericsson em 1986 para a linguagem Erlang, essas tecnologias foram as principais protagonistas para aplicações em ambiente telecom lidando com incontáveis requests por segundo de forma confiável e performática.

Algumas décadas depois, essa VM foi considerada para a web pela primeira vez por José Valim, que criou a linguagem Elixir em meados de 2011 para utilizar todo o poder da BEAM em uma linguagem moderna e com foco na experiência de desenvolvimento. Essa linguagem foi também a responsável pela popularização da máquina virtual e provavelmente você não estaria lendo este artigo se não fosse por ela, não é mesmo? 👀

Mas afinal...Por que essa maquina virtual foi criada? Quais suas vantagens, poderes e o mais importante: quais seus segredos? Nesse artigo vamos nos aventurar brevemente nos detalhes dessa VM, vem que vem!

O que é a BEAM
Stack machine vs Register machine
O que significa ser simultâneo por padrão
Um caso interessante para fazer nodes interagirem pela rede
Conclusão

O que é a BEAM

A BEAM é uma das partes que compõem o sistema OTP e atua semelhante a como a JVM funciona para o java, seus objetivos principais são performance, concorrência, tolerância a erros e o uso de threads leves para executar computações de forma concorrente o máximo possível.

Interagir com essa VM pode ser feito de 2 formas principais:

1. Compilar uma linguagem X para Erlang e utilizar o próprio compilador do Erlang para gerar o bytecode *.beam (Como é o caso da linguagem gleam que possui Erlang como um de seus targets)
2. Compilar uma linguagem X para o bytecode *.beam de forma direta (Como é o caso do elixir)

Apesar de ser muito mencionada como a ultima layer de execução, a BEAM é apenas um dos componentes que compõem todo processo de execução de uma aplicação Erlang/Elixir/Gleam, no diagrama abaixo podemos ver exatamente em que ponto a VM se encaixa:

Como é possível observar, a BEAM roda dentro do runtime Erlang (ERTS) e consequentemente todo o código da nossa aplicação rodam como um node* independente na VM.

node* pode ser entendido de maneira breve como uma thread do sistema operacional. Cada node pode ter milhares de processos rodando ao mesmo tempo e esses processos são threads leves que imitam o comportamento de uma nativa do sistema operacional possuindo as seguintes capacidades: comunicar entre si por meio de signals, executar computações e iniciar outros processos.

Stack machine vs Register machine

Bom, eu poderia simplesmente te dizer que a BEAM é uma maquina de registros com capacidades de uma maquina de stack, mas isso não seria muito útil né? Então vamos voltar do começo e entender o que é cada coisa:

O que é uma stack machine

Podemos falar que uma stack machine é a forma mais comum de se criar um interpretador, justamente por ter um modelo mental simples de compreender e pelo fato do código final gerado ser super simples de compreender por humanos, pense nesse modelo como uma fila FIFO onde temos 2 ações principais:

1. push: Insere um valor na fila
2. pop: Tira um valor da fila

Mas...só isso? SIM!! Com esse conceito podemos traduzir a expressão exemplo 2 + 2 como se fosse interpretada por uma stack machine 👇:

push 2
push 2
add

É eu sei, tem uma palavra add ali né? Mas ela está completamente alinhada com o conceito de stack não se preocupe, nesse caso o add representa uma chamada de uma função e tudo o que ela faz é remover os argumentos da pilha (utilizando pop) e depois adicionar o resultado da operação de volta a fila (utilizando push), abaixo podemos ver em mais detalhes esse processo:

push 2 #=> Adiciona 2 a stack
push 2 #=> Adiciona 2 a stack
add #=> detalhe da execução abaixo
    pop #=> Remove argumento da stack
    pop #=> Remove argumento da stack
    push 4 #=> Adiciona o resultado 4 a stack

O que é uma register machine

Diferente da stack machine, uma register machine usa de registros para armazenar tanto valores de argumentos quanto seus resultados e nenhum desses valores é removido justamente por ter a capacidade de utilizar múltiplos registros para diferentes coisas (a BEAM utiliza um registro X0 para guardar resultados de computações).

Por ter a capacidade de trabalhar com mais registradores, uma register machine possui mais operadores da manipulação como move, swap e também formas de acessar o valor de um registrador de forma específica como podemos ver em mais detalhes abaixo:

{function, add, 2, 2}.
  {label,1}.
    {line,[{location,"add.erl",4}]}.
    {func_info,{atom,add},{atom,add},2}.
  {label,2}.
    {allocate,1,2}. #=> Prepara um lugar na memoria para eventualmente armazenar os valores
    {move,{x,1},{y,0}}. #=> Copia o argumento da função (salvo automaticamente no registrador x) para um registrador temporario y
    {call,1,{f,4}}.
    {swap,{y,0},{x,0}}. #=> Inverte os valores de cada registrador
    {call,1,{f,4}}.
    {gc_bif,'+',{f,0},1,[{y,0},{x,0}],{x,0}}. #=> Soma os numeros nos registradores x e y, sobrescrevendo então o registrador x com o resultado
    {deallocate,1}.
    return.

PS: Esse artigo não se propõe em te ensinar exatamente como funcionam registradores e muito menos assembly (até porque nem eu sei tanto sobre 😅), mas sim prover uma visão geral de como esse modelo se comporta.

E o que é a BEAM afinal?

Agora acredito que podemos entender a frase inicial certo? A BEAM é uma register machine que possui stacks em registradores específicos (no caso o Y), pois dessa forma se torna mais simples transitar valores de argumentos por exemplo.

O que significa ser simultâneo por padrão

Se você leu o suficiente sobre elixir ou alguma outra linguagem do ecossistema já deve ter ouvido falar que a BEAM é simultânea por padrão, mas afinal o que isso quer dizer? Em suma quer dizer que as linguagens da BEAM fornecem formas nativas e inteligentes de lidar com computações concorrentes.

Como vimos anteriormente, toda nossa aplicação roda em um dos nodes da VM e esse node pode ter milhares de processos (como também foi falado sobre termos processos leves) executando computações simultaneamente. Esses processos são nossa principal forma de garantir simultaneidade durante a nossa aplicação, nativamente temos funções como spawn para iniciar novos processos e utilizando essa função primária temos abstrações inteiras como GenServer e Task que possibilitam o uso de processos em contextos específicos.

E não é só de iniciar novos processos que uma aplicação simultânea vive não é mesmo? As linguagens da BEAM também fornecem construtores nativos para lidar com troca de mensagens entre processos por meio de mailboxes. Essas mailboxes são blocos que funcionam como um switch case, cada branch pode ser correspondida utilizando padrões como mostrado abaixo 👇:

Em elixir

iex(1)> defmodule Listener do
...(1)> def call do
...(1)> receive do
...(1)> {:hello, msg} -> IO.puts("Received inside the mail: #{msg}")
...(1)> end
...(1)> end
...(1)> end
{:module, Listener,
 <<70, 79, 82, 49, 0, 0, 6, 116, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 240,
   0, 0, 0, 25, 15, 69, 108, 105, 120, 105, 114, 46, 76, 105, 115, 116, 101,
   110, 101, 114, 8, 95, 95, 105, 110, 102, 111, ...>>, {:call, 0}}
iex(2)> pid = spawn(&Listener.call/0)
#PID<0.115.0>
iex(3)> send(pid, {:hello, "Hello World"})
Received inside the mail: Hello World
{:hello, "Hello World"}
iex(4)>

Em erlang

1> c("mailbox.erl").
{ok,mailbox}
2> mailbox:module_info().
[{module,mailbox},
 {exports,[{call,0},{module_info,0},{module_info,1}]},
 {attributes,[{vsn,[330096396114390727100476047769825248960]}]},
 {compile,[{version,"8.4.3"},
           {options,[]},
           {source,"/private/tmp/NKI90h/mailbox.erl"}]},
 {md5,<<248,86,64,221,149,120,150,9,30,225,159,226,217,
        253,6,192>>}]
3> Pid = spawn(fun mailbox:call/0).
<0.93.0>
4> Pid ! {hello, "Hello World"}.
Received inside the mail: "Hello World"
{hello,"Hello World"}
5>

Com isso temos todas as ferramentas necessárias para entender como as linguagens da BEAM fornecem simultaneidade por padrão apenas por definir suas abstrações de forma concorrente desde o ponto inicial, legal né?!

Dica bonus: Tenho uma série de artigos falando sobre essas abstrações na linguagem Elixir: https://dev.to/cherryramatis/handling-state-between-multiple-instances-with-elixir-4jm1

Um caso interessante para fazer nodes interagirem pela rede

Vamos relembrar algumas coisas legais por aqui, primeiro sabemos que ao iniciarmos uma nova aplicação Erlang/Elixir a mesma executa em um node da BEAM, e em segundo sabemos que temos construtores nativos da linguagem para manipular processos que executam dentro desse node e podem se comunicar por troca de mensagem certo?

Agora e se eu te dissesse que os nodes também podem se comunicar? Isso mesmo! A BEAM é realmente a tecnologia perfeita para software distribuído, em um famoso video do Honeypot o José Valim explica essa interação que eu vou descrever aqui embaixo, o video pode ser visto em: https://www.youtube.com/watch?v=lxYFOM3UJzo a partir do minuto 4:41

Para fazer jus ao José Valim vamos realizar o exemplo em elixir da mesma forma que ele fez no video, mas é possível fazer com Erlang da mesma forma.

Para iniciar sistema elixir em um node da BEAM vamos iniciar o REPL interativo com um nome de host e vamos definir um modulo exemplo que printa "Hello world" na tela:

🍒 iex --name cherry
Erlang/OTP 26 [erts-14.2.5] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit] [dtrace]

Interactive Elixir (1.17.0-dev) - press Ctrl+C to exit (type h() ENTER for help)
iex(cherry@Cherrys-Laptop.local)1> defmodule Hello do
...(cherry@Cherrys-Laptop.local)1> def world do
...(cherry@Cherrys-Laptop.local)1> IO.puts("Hello World")
...(cherry@Cherrys-Laptop.local)1> end
...(cherry@Cherrys-Laptop.local)1> end
{:module, Hello,
 <<70, 79, 82, 49, 0, 0, 5, 72, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 184,
   0, 0, 0, 19, 12, 69, 108, 105, 120, 105, 114, 46, 72, 101, 108, 108, 111, 8,
   95, 95, 105, 110, 102, 111, 95, 95, 10, ...>>, {:world, 0}}
iex(cherry@Cherrys-Laptop.local)2> Hello.world
Hello World
:ok
iex(cherry@Cherrys-Laptop.local)3>

Em outro terminal, vamos iniciar um novo REPL com outro nome e vamos tentar executar o modulo que foi definido na instancia acima:

🍒 iex --name kalane
Erlang/OTP 26 [erts-14.2.5] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit] [dtrace]

Interactive Elixir (1.17.0-dev) - press Ctrl+C to exit (type h() ENTER for help)
iex(kalane@Cherrys-Laptop.local)1> Hello.world
** (UndefinedFunctionError) function Hello.world/0 is undefined (module Hello is not available)
    Hello.world()
    iex:1: (file)
iex(kalane@Cherrys-Laptop.local)1>

Bom...nada é tão simples né? Na verdade precisamos utilizar o modulo de Node para tornar essa comunicação possível, vamos executar agora a seguinte linha no mesmo REPL que estávamos:

iex(kalane@Cherrys-Laptop.local)1> Node.spawn(:"cherry@Cherrys-Laptop.local", fn -> Hello.world() end)
Hello World
#PID<13525.123.0>
iex(kalane@Cherrys-Laptop.local)2>

Sua cabeça explodiu? Eu espero que sim porque isso estamos comunicando duas instancias separadas do elixir dentro de uma mesma rede de forma completamente nativa da linguagem (pra que Kubernetes /j).

Com essa tecnologia podemos construir sistemas inteiros de pub sub e notificação sem precisar depender de SaaS dedicados, apenas utilizando as funcionalidades que a VM já entrega.

Conclusão

Nesse artigo tentei ao máximo repassar meus últimos estudos com a BEAM e principalmente repassar meu entusiasmo e momentos de descoberta porque certamente foi uma série constante de "mind blown" a medida que fui lendo e pesquisando.

Meus estudos envolveram principalmente tentar recriar um arquivo .beam a partir de uma linguagem fictícia que só define funções retornando valores estáticos, o projeto tem uma versão em rust inicial e uma versão WIP em elixir e pode ser encontrado no link: https://github.com/cherryramatisdev/beam_studies

Referências

May the force be with you 🍒

DEV Community: Cherry Ramatis

[Boost]

[Boost]

[Boost]

[Boost]

[Boost]

[Boost]

[Boost]

Native Fuzzy Finder in Neovim With Lua and Cool Bindings

Breaking up piece by piece

Final thoughts

[Boost]

[Boost]

How I learn any type of new technology (As a Senior Developer)

Daniel Reis ・ Mar 20 '25

I'm looking for a FullStack Software Developer Role

A little bit to know me

Achievements that I'm proud of

My favorite projects

How you can reach me

BEAM VM The good, the bad and the ugly

Table of contents

O que é a BEAM

Stack machine vs Register machine

O que é uma stack machine

O que é uma register machine

E o que é a BEAM afinal?

O que significa ser simultâneo por padrão

Um caso interessante para fazer nodes interagirem pela rede

Conclusão

Referências