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

Comments 14

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 🍒

Ending the war or continuing it? Let's bring functional programming to OOP codebases

Cherry Ramatis — Wed, 06 Mar 2024 21:01:42 +0000

The more time goes by, the more I become a functional programming enthusiast. Even when I'm working in an OOP codebase, I try to apply small concepts aimed at simplifying the code and predicting outcomes more easily. As a Rubyist, I also love how functional code is trivial to write unit tests.

The goal of this article is to share my views on functional programming concepts and propose an approach where we can use functional concepts within your already written OOP code. Hopefully, we'll stop arguing about which paradigm is better and start composing good ideas to produce increasingly better code each time!

In the beginning, there was Functional Programming
Entering OOP, what is this paradigm?
What is a class and how can we think about it differently
To mutate or not to mutate: What is immutability
The monster under the bed: what are side effects
Isolate everything: what are pure functions
Using functional patterns without going full haskell
Conclusion

In the beginning, there was Functional Programming

The functional programming paradigm emerged in 1958 with the advent of the first Lisp language (good old days). Its roots can be traced back to the lambda calculus by Alonzo Church. The core principle of functional programming revolves around minimizing the dependence on state within the codebase.

In contrast to Object-oriented Programming (OOP), which allows state but emphasizes encapsulation, functional programmers strive to prioritize writing components that are stateless. This approach encourages the creation of code that is independent of external state variables.

Furthermore, even when state is introduced, it is essential to write it thinking about immutability, purity of functions and even avoiding side effects. All this concepts will be covered further as the article goes.

Entering OOP, what is this paradigm?

OOP, or better known as Object-Oriented Programming, is a paradigm dating back to 1967. Its greatest representatives are Simula, Smalltalk, and Java. The thought process behind it is to reduce the amount of "global" state by enforcing encapsulation practices to group those states and any behavior modifying them under a common "entity" or "object."

In fact, the name "Object-Oriented Programming" has been widely discussed over the years. One of the creators of OOP, Alan Key, actually wanted to focus more on the messaging aspect of the paradigm. This means that we should emphasize encapsulation and allow communication of state and behavior between objects. Perhaps in a different universe, we could have had "Messaging-Oriented Programming." However, the name OOP has endured over the years, and here we are!

I don't know about you, but this simple process of considering another possible name for the paradigm made my mind go crazy, rethinking some concepts and actually simplifying the way I architect my software.

What is a class and how can we think about it differently

I think everyone has had that classic lecture where we were taught about a class "Animal" that includes a class "Dog," right? You probably heard those same words (at least I did).

A class is a blueprint for an entity in the real world, describing its characteristics and actions.

While not incorrect, I would like to suggest a slight change in word usage to help clarify the encapsulations for better understanding, as it did for me. Let's consider the following new quote:

A class is a way to encapsulate state and behaviors that operate on that state.

This simple word change really made a twist in my mind. I stopped trying to think of classes as real-world entities and started to think simply as another way to group state with similar context together and expose functions to operate on those states. I hope this slight change also helps you review your own concepts!

The importance of abstracting this concept in such a way is to become proficient when reading code from languages with different constructs such as modules. We can observe that this OOP code written in typescript:

class Github {
  private _url: string;
  private _repo: string;
  private _username: string;

  constructor(url: string, repo: string, username: string) {
    this._repo = repo
    this._username = username
    this._url = url
  }

  public createRepo(name: string): void {
    // TODO: do stuff here using the provided state in _url, _repo and _username
  }
}

Is completely equivalent to this elixir code, even though the elixir code use "modules" instead of "classes":

defmodule Github do
  @url ""
  @repo ""
  @username ""

  defstruct url: @url, repo: @repo, username: @username

  def new(url, repo, username) do
    %Github{url: url, repo: repo, username: username}
  end

  def create_repo(%Github{repo: repo, username: username}, name) do
    # TODO: do stuff here using the provided state in url, repo, and username
  end
end

Next we'll look into some functional concepts and further discuss the merge of those paradigms, let's go!

To mutate or not to mutate: What is immutability

Now we're reaching the first real functional concept, and a very important one, I may add (everything is planned here)! To understand immutability properly, let's review the ways we deal with values in programming:

Typically, we bind values to variables so we can operate on them later, right? Something as simple as

# Bounding values to variables
name = 'Cherry'
age = 23

# Operating on it and bounding to another variable
year_born = Time.now.year - age

# Printing it
puts "#{name} has #{age} years old and was born at #{year_born}"

With these variables, it's quite common to make changes to the original variable by updating its values, but the missing piece here is: modifying a variable is a destructive action.

But... why? Well, let's imagine multiple operations (functions or blocks of code) modifying the same variable at different moments and frequencies. With this situation, we create a lot of problems such as:

1. Inability to reorder the operations or change them at all: When we have so much dependent code, it's even hard to reorder or change the code because everything is bound to a specific order of changes.
2. Mental overhead to understand what the code is doing: Although this is a personal opinion, I think it's a widely agreeable one. Highly mutable code can easily become messy and cryptic to understand the data flow, requiring tools such as a debugger to step through the transformations.
3. Difficulties while testing: Mocking a particular state of the function transformations is really hard, and this will gradually expand your unit tests until they aren't units anymore.

Immutability can be defined as a practice to avoid changing (or mutating) any variable inside our program. Although depending on the language, we may need to make concessions and mutate some controlled variables, the overall lesson to be learned here is:

We should avoid mutating variables with no defined scope at all costs.

With this phrase, I mean that it's okay to create a scoped variable inside a function and mutate it there. However, as soon as you pass this mutable variable to another function, you will increase the number of targets mutating the same variable, and your control will slowly be lost. This is the exact situation that we want to avoid!

The monster under the bed: what are side effects

This topic generates a lot of heat whenever someone raises it for discussion. I may not cover every nuance of this subject, but I will definitely explain to you what they are and how I manage side effects in my own software, okay?

Well then, side effects are every computation that interacts with outside resources (or "outside world") by calling a protocol (HTTP, WebSocket, GraphQL, etc.) or even manipulating stdin/stdout. Yeah, I know, even our harmless print gets the blame here. 😔

But different from mutability, instead of avoiding the usage as much as possible, we should isolate it in specific functions that deal with the side effect alone. This way, we separate our code into "functions that do not perform any side effects" and "functions that perform side effects." But why worry about this separation at all?

Every time we trigger any action to the "outside world," we lose control over what can happen for this particular piece of computation (like when performing an HTTP call, the server may be down or may not exist at all). Other problems include the difficulty of testing and a reduction in the predictability of the code.

Since we can't write any real-world software without side effects, the general advice is to clusterize it into small functions that handle it separately with a proper abstraction around errors. That way, it's possible to test only the function that we control 100% and mock all the functions that perform side effects.

For example, consider the following function that performs an HTTP request and small functions that transform the data returned from it.

require 'faraday'

module MyServiceModule
  # This function perform side effects
  def perform_http_request
    conn = Faraday.new(url: "fakeapi.com")

    begin
      response = conn.get
      {ok: true, data: response.body}
    rescue  => e
      {ok: false, error: e}
    end
  end

  # These functions doens't perform any side effects
  def upcase_name(name)
    return '' unless name.is_a?(String)

    name.upcase
  end

  def retrieve_born_year(age)
    return 0 unless age.is_a?(Integer)

    Time.now.year - age
  end
end

See how I said about a "abstraction around error" ? This is exactly what was implemented on the code example above, instead of letting the exception bubble up our code we abstracted against a Hash.

After defining these functions with clear definition between "side effects" and "no side effects" it's really easy to predict what will happen in our code and also easier to test as you can see below:

require 'minitest/autorun'

class TestingStuff < Minitest::Test
  def test_upcase_name
    assert_equal MyServiceModule.upcase_name "cherry", "CHERRY"
    assert_equal MyServiceModule.upcase_name "kalane", "KALANE"
    assert_equal MyServiceModule.upcase_name "Thales", "THALES"
  end

  def test_retrieve_born_year
    Time.stub :now, Time.new(2024, 3, 5) do
      assert_equal MyServiceModule.retrieve_born_year 23, 2001
      assert_equal MyServiceModule.retrieve_born_year 20, 2004
      assert_equal MyServiceModule.retrieve_born_year 14, 2010
    end
  end
end

This strategy is really great because you don't even need to worry about the side effect part when testing, just write assertions for the transformation part of the code that actually do something and you'll end up with better tests that actually validate the important part of your codebase! Neat right?

Isolate everything: what are pure functions

Now it's time to wrap up all the knowledge gained so far. In the previous example, we observed code separated into "side effects" and "no side effects." We also saw how these functions are easier to test and that our main transformation business logic should be kept isolated. Are you wondering what these functions are called? They are pure functions!

Let's examine a proper formal definition of pure functions and explore the concept step by step.

Pure functions are functions that respect immutability, do not perform any side effects, and return the same output given the same parameters.

Basically, pure functions respect all the principles we previously mentioned, plus they always produce the same return for the same parameters. Let's take a look at our previous functions.

def upcase_name(name)
  return '' unless name.is_a?(String)

  name.upcase
end

upcase_name('cherry') # => Will be *always* CHERRY

With pure functions, we can easily define multiple assertions because we aren't bound to any context that requires extensive mocking. We simply pass the required parameters with static values, and that's it!

Since pure functions are very small and composable, their number increases very quickly. To handle this, functional languages like Elixir provide composition operators like the pipeline, which make it really easy to execute multiple pure functions in sequence.

"cherry  "
|> trim
|> upcase # => "CHERRY"

The pipeline operator originates from functions like Bash. You can read more about it here: [https://dev.to/cherryramatis/linux-filters-how-to-streamline-text-like-a-boss-2dp4#what-is-a-pipeline]

Using functional patterns without going full haskell

I always feared learning the functional paradigm because the community made it look really complicated by using ready-made sentences and big concepts for everyone trying to learn some small tips. After grasping many functional languages and trying to learn as much as I can, my goal became to simplify those concepts and, most importantly, advocate for using functional concepts even in your OOP code.

Applying pure functions (or pure methods, if you prefer), immutability, and separation of side effects can make your OOP code look a lot cleaner and decoupled. You don't need to know what a monad is or how to write a compiler by hand in Haskell; you can simply stick with your Ruby on Rails using simple and effective functional concepts!

I hope that with this small article (and the ones that will come in this series) you can improve your codebase with composability and simplicity, no matter which language and framework you choose.

Conclusion

This article is my attempt to democratize the knowledge of the functional paradigm (within my capabilities and expertise). It's important to emphasize that I'm not a functional expert, and this article is targeted at beginners who know OOP and have an interest in functional programming. I hope it's useful, and I'm willing to help with whatever is needed. May the force be with you 🍒

DEV Community: Cherry Ramatis

[Boost]

Your Swagger Doc Is More Than Documentation — It's a Test Suite Waiting to Happen

[Boost]

API vs Event Streaming: O Que Muda Para Quem Testa? - DEV Community

[Boost]

Análise de correspondência, o que é e como fazer com Python, usando Naruto como exemplo

[Boost]

Rewriting My First NUnit API Tests: Cleaner, Faster, Better

[Boost]

From Swagger to Tests: Building an AI-Powered API Test Generator with Python

[Boost]

Entendendo o consumo de memória do Gitaly e Kernel no Kubernetes em Gitlab self-hosted

Native Fuzzy Finder in Neovim With Lua and Cool Bindings

Breaking up piece by piece

Final thoughts

[Boost]

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

[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

Ending the war or continuing it? Let's bring functional programming to OOP codebases

Table of Contents

In the beginning, there was Functional Programming

Entering OOP, what is this paradigm?

What is a class and how can we think about it differently

To mutate or not to mutate: What is immutability

The monster under the bed: what are side effects

Isolate everything: what are pure functions

Using functional patterns without going full haskell

Conclusion