DEV Community: renanbastos93

Funções anônimas são mais lentas em Go? Medi os 6 cenários e só 1 custa caro

renanbastos93 — Tue, 03 Nov 2026 17:39:14 +0000

Introdução

Esse é um mito extremamente comum em code review de Go, inclusive em times experientes.

O roteiro é quase sempre o mesmo:

alguém roda um benchmark
vê uma diferença de ns/op
conclui que função anônima é mais lenta
abre um PR trocando closures por funções nomeadas

Na maioria dos casos, o culpado apontado é este aqui:

func(v int) int {
    return v + 1
}

E quase sempre o culpado é outro.

TL;DR

Função anônima não é mais lenta. Medi: 1,614 ns/op nas duas versões, diferença de 0%
Closure não significa heap allocation. Capturar variável pode ficar 100% na stack
Dos 6 cenários que medi, só 1 aloca, e é 3,2× mais lento
O único que aloca é a closure criada a cada operação e que sobrevive à função que a criou
ns/op é ruído. B/op e allocs/op são comportamento
O caso mais caro nem aparece no benchmark: closure que segura um objeto grande vivo (medi 100 MB presos por 1 byte usado)

Neste post você vai entender

O que realmente custa em uma closure
Como provar com benchmark, escape analysis e pprof
Por que ns/op engana e o que olhar no lugar
O caso de retenção de memória que allocs/op não mostra
Quando usar função anônima sem medo, e quando investigar

Todo o código está no fim do post. Você reproduz com um comando.

O problema

O mito em uma linha:

função anônima = heap allocation = lento

Nenhuma das duas igualdades é verdadeira.

Compare:

// nomeada
func addOne(v int) int {
    return v + 1
}

// anônima
func(v int) int {
    return v + 1
}(42)

O compilador enxerga a expressão inteira na segunda versão. Ele inlina as duas.

Mesmo código de máquina. Mesmo custo.

O custo não vem da sintaxe. Vem de outra coisa.

O que realmente custa

Uma função normal recebe tudo pelos parâmetros:

func addOne(v int) int {
    return v + 1
}

Uma closure carrega contexto junto:

offset := 10

fn := func(v int) int {
    return v + offset
}

offset não chegou por parâmetro. A função precisa lembrar dele.

É como se ela carregasse uma mochila:

Closure
┌─────────────────────┐
│ código da função    │
│ contexto capturado  │
│ └── offset = 10     │
└─────────────────────┘

Isso ainda não significa heap.

A pergunta que decide tudo é:

Por quanto tempo esse contexto precisa existir?

Se ele morre junto com a função atual, fica na stack. Se sobrevive, vai para o heap.

Quem decide isso é o escape analysis do compilador:

            captura variável
                   │
                   ▼
             ela escapa?
              /        \
            não         sim
             │           │
             ▼           ▼
           stack        heap

Então:

capturar variável ≠ ir para o heap

Vamos provar.

Provando com uma POC

Seis cenários, do mais simples ao mais caro:

package closurebench

import "testing"

var (
    sinkInt int
    sinkFn  func(int) int
)

func addOne(v int) int {
    return v + 1
}

func makeAdder(delta int) func(int) int {
    return func(v int) int {
        return v + delta
    }
}

// 1. função nomeada, chamada direta
func BenchmarkNamedDirect(b *testing.B) {
    for b.Loop() {
        sinkInt = addOne(42)
    }
}

// 2. função anônima executada na hora
func BenchmarkAnonymousImmediate(b *testing.B) {
    for b.Loop() {
        sinkInt = func(v int) int {
            return v + 1
        }(42)
    }
}

// 3. closure que captura, mas não sobrevive ao loop
func BenchmarkCapturedNonEscaping(b *testing.B) {
    delta := 1

    for b.Loop() {
        fn := func(v int) int {
            return v + delta
        }

        sinkInt = fn(42)
    }
}

// 4. closure criada UMA vez e reutilizada
func BenchmarkClosureReused(b *testing.B) {
    fn := makeAdder(1)

    for b.Loop() {
        sinkInt = fn(42)
    }
}

// 5. chamada através de um function value
func BenchmarkIndirectFunctionValue(b *testing.B) {
    sinkFn = addOne

    for b.Loop() {
        sinkInt = sinkFn(42)
    }
}

// 6. closure NOVA a cada operação, que sobrevive
func BenchmarkEscapingClosureCreation(b *testing.B) {
    delta := 1

    for b.Loop() {
        sinkFn = makeAdder(delta)
        delta++
    }
}

Rodando:

go test -bench=. -benchmem -count=10

Resultado (go1.27.1, Apple M4, resumido com benchstat):

#	Cenário	ns/op	B/op	allocs/op
1	nomeada direta	1,614	0	0
2	anônima imediata	1,614	0	0
3	closure sem escape	1,889	0	0
4	closure reutilizada	1,617	0	0
5	function value	1,695	0	0
6	closure escapando	5,160	16	1

Olhe a coluna allocs/op.

Cinco zeros e um um.

Atenção: o número absoluto engana

Antes de interpretar, uma armadilha que quase me pegou.

Repeti a medição na mesma máquina, mesmo binário, 40 minutos depois. A única diferença: o notebook saiu da tomada e entrou em low power mode.

Cenário	Na tomada	Na bateria	Razão A	Razão B
nomeada direta	1,614	3,358	1,00	1,00
anônima imediata	1,614	3,358	1,00	1,00
closure sem escape	1,889	3,646	1,17	1,09
closure reutilizada	1,617	3,358	1,00	1,00
function value	1,695	3,415	1,05	1,02
closure escapando	5,160	9,485	3,20	2,82

Todos os tempos dobraram.

B/op e allocs/op não mudaram em nenhuma linha.

A regra que fica:

ns/op       → depende de CPU, clock, energia, carga
              não é reproduzível

B/op        → é comportamento gerado pelo compilador
allocs/op     é reproduzível

Compare razões, nunca nanossegundos.

A tabela não é um ranking

Essa é a leitura errada mais fácil de fazer.

Dá vontade de ordenar os seis do mais rápido ao mais lento. Mas os cinco primeiros estão empatados dentro do ruído:

┌─────────────────────────────────┐
│  NÃO ALOCA                      │
│                                 │
│  nomeada direta         1,00×   │
│  anônima imediata       1,00×   │
│  closure reutilizada    1,00×   │
│  function value         1,05×   │
│  closure sem escape     1,17×   │
└─────────────────────────────────┘
                 ⬇ salto
┌─────────────────────────────────┐
│  ALOCA                          │
│                                 │
│  closure escapando      3,20×   │
└─────────────────────────────────┘

A separação não é gradual. É binária: aloca ou não aloca.

Na segunda amostra, o function value caiu de 1,05× para 1,02×. A closure sem escape, de 1,17× para 1,09×.

A única diferença que sobreviveu à troca de ambiente foi a alocação.

Provando com escape analysis

Não precisa acreditar em mim. Pergunte ao compilador:

go test -run='^$' -gcflags='-m=2' ./...

A saída do código acima inclui exatamente estas linhas:

closure_bench_test.go:14:16: makeAdder capturing by value: delta (width=8)
closure_bench_test.go:14:6:  can inline makeAdder with cost 17
closure_bench_test.go:15:9:  func literal escapes to heap     ← cenário 6
closure_bench_test.go:38:9:  func literal does not escape     ← cenário 3

As duas últimas linhas são o post inteiro.

Mesma sintaxe. Mesmo tipo de closure. Destinos opostos.

O que muda entre elas não é como você escreveu. É se o contexto precisa sobreviver.

Provando com pprof

O benchmark diz quanto. O pprof diz onde.

Coletando:

go test -run='^$' \
  -bench=BenchmarkEscapingClosureCreation \
  -benchmem \
  -memprofile=mem.out \
  -o closurebench.test

go tool pprof -alloc_space -top closurebench.test mem.out

O caminho é este:

  benchmark roda
        │
        │  -memprofile=mem.out
        ▼
┌────────────────────┐
│      mem.out       │  cada alocação + seu stack trace
└────────────────────┘
        │
        │  go tool pprof
        ▼
┌──────────────────────────────────────┐
│  -alloc_space    quantos BYTES        │  ← allocation rate
│  -alloc_objects  quantos OBJETOS      │
│  -inuse_space    o que continua VIVO  │  ← live heap
└──────────────────────────────────────┘
        │
        ▼
  linha exata do código

Guarde a diferença entre a primeira e a última flag. Vamos precisar dela daqui a pouco.

A saída:

Type: alloc_space
Showing nodes accounting for 3.34GB, 99.94% of 3.34GB total

      flat  flat%        cum   cum%
    3.34GB 99.94%     3.34GB 99.94%  closurebench.makeAdder (inline)
         0     0%     3.34GB 99.94%  closurebench.BenchmarkEscapingClosureCreation

E em objetos:

Type: alloc_objects

 224136539   100%   224136539   100%  closurebench.makeAdder (inline)

Visualmente:

        onde alocou               quanto
┌────────────────────────────┬──────────┐
│ makeAdder (inline)         │  3.34GB  │ ████████████
│ todo o resto               │   ~2MB   │ ▏
└────────────────────────────┴──────────┘

Fecha a conta: 224.136.539 objetos × 16 B = 3,34 GB.

Cem por cento da alocação em uma linha de código, exatamente onde a closure escapa.

E aqui aparece o ponto sobre frequência. Dezesseis bytes parecem irrelevantes. Multiplicados por 224 milhões, viram 3,34 GB que o allocator e o GC tiveram que processar.

custo × frequência

Se preferir navegar em vez de ler:

go tool pprof -http=:8080 closurebench.test mem.out

Abre flame graph e visão por linha no navegador.

O caso que o benchmark não mostra: live heap

Esse é o mais caro de todos. E ele não aparece em allocs/op.

Considere:

func firstByte(buf []byte) func() byte {
    return func() byte {
        return buf[0]
    }
}

Agora:

buf := make([]byte, 100*1024*1024) // 100 MB

fn := firstByte(buf)

A closure usa 1 byte.

Mas ela capturou buf. E o slice referencia o backing array inteiro:

closure
   │
   ▼
slice
   │
   ▼
100 MB backing array

Enquanto a closure estiver alcançável, os 100 MB também estão. O GC não pode coletar.

Escrevi um teste que mede o heap vivo depois de um runtime.GC(), com a closure ainda viva:

live heap retido: 104.779.808 bytes

Cem megabytes presos por causa de um byte.

A correção

Capture só o que você precisa:

// antes segura 100 MB
func firstByte(buf []byte) func() byte {
    return func() byte {
        return buf[0]
    }
}

// depois segura 1 byte
func firstByte(buf []byte) func() byte {
    first := buf[0]

    return func() byte {
        return first
    }
}

Mesmo teste, mesma medição:

live heap retido: -40.160 bytes

Negativo porque o GC ainda limpou lixo residual. Na prática: zero.

E o compilador confirma:

retention_test.go:19:29: buf does not escape

ANTES              DEPOIS

closure            closure
   │                  │
   ▼                  ▼
slice               byte
   │
   ▼
100 MB

Uma linha de código. De 100 MB para 1 byte.

É por isso que existem duas perguntas diferentes:

Conceito	Pergunta	Flag do pprof
Allocation rate	quanta memória nova por segundo?	`-alloc_space`
Live heap	quanto continua alcançável?	`-inuse_space`

O benchmark só enxerga a primeira.

E o caso é pior quando a closure captura algo como req *Request, que referencia User, Session, Headers, Buffer, Cache. Uma closure pequena mantendo um grafo inteiro vivo.

Function value: o custo não é a chamada indireta

Aqui eu esperava achar um vilão e não achei. Vale contar por quê.

A intuição diz que isto é mais caro:

var fn func(int) int = addOne

sinkInt = fn(42)

porque o compilador não conhece o destino direto.

Medido: 1,695 contra 1,614 ns/op. Cinco por cento que viraram dois na segunda amostra.

Testei também se o problema seria alvo imprevisível. Um benchmark chama sempre a mesma função; o outro alterna entre quatro:

Benchmark	ns/op
alvo sempre o mesmo	1,758
quatro alvos em rodízio	1,762

Idênticos. A indireção em si é quase de graça em CPU moderna.

O custo real é outro:

function value
      ↓
compilador não sabe o destino
      ↓
não consegue inlinar

E isso só importa quando existe algo que valha a pena inlinar.

addOne é return v + 1. Não há o que ganhar. Troquei por um corpo maior, um loop de oito iterações:

Chamada	ns/op
direta, inlinável	2,57
via function value	3,51

Agora sim: 36% a mais.

Ou seja:

named function    ≠ automaticamente rápida
anonymous function ≠ automaticamente lenta

O que importa é o que o compilador conseguiu gerar e o que ele deixou de conseguir.

Regra de ouro

Não otimize a sintaxe. Otimize o comportamento gerado.

Na prática, isso vira três perguntas:

A closure escapa? (escape analysis responde)
Ela aloca por operação? (benchmark responde)
Ela segura algo grande vivo? (-inuse_space responde)

Se as três respostas forem não, não existe otimização a fazer.

Como investigar, na ordem certa

1. Benchmark

go test -bench=. -benchmem -count=10

Máquina ociosa e na tomada. Já mostrei o que acontece quando não é.

2. Escape analysis

go test -run='^$' -gcflags='-m=2' ./...

Procure por escapes to heap, does not escape, capturing by value, can inline.

3. Memory profile

go test -bench=. -benchmem -memprofile=mem.out
go tool pprof -alloc_space mem.out

Onde estou alocando, em vez de onde eu acho que estou.

4. Compare antes e depois

go test -bench=. -count=10 > before.txt
# ... sua mudança ...
go test -bench=. -count=10 > after.txt

benchstat before.txt after.txt

O benchstat diz se a diferença é sinal ou ruído. Uma execução única não diz nada.

Use função anônima sem medo aqui

Callbacks:

slices.SortFunc(users, func(a, b User) int {
    return cmp.Compare(a.Age, b.Age)
})

Handlers:

http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusOK)
})

Goroutines:

go func() {
    process()
}()

Defer:

defer func() {
    cleanup()
}()

Nesses casos você ganha localidade, legibilidade e encapsulamento. E, pelos números acima, não paga nada por isso.

Investigue quando aparecerem juntos

closure + hot path + alta frequência + allocation

Exemplo clássico:

for _, item := range millionsOfItems {
    fn := createProcessor(item)   // closure nova a cada item

    queue = append(queue, fn)     // e todas sobrevivem
}

Ou closures guardadas por muito tempo em slice, map, queue, channel ou variável global.

E, principalmente: closures que capturam estruturas grandes.

E aumentar o GOGC resolve?

Não.

GOGC maior              GOGC menor
    ↓                       ↓
GC menos frequente      GC mais frequente
mais memória            menos memória

É uma troca entre CPU e memória. É runtime tuning.

Não remove uma allocation desnecessária de um hot path.

E zerar todas as allocations?

Também não.

Uma operação que roda 10 vezes por minuto: 1 alloc/op não importa.

A mesma operação 5 milhões de vezes por segundo: muda tudo.

Performance precisa de contexto.

Comparativo final

Situação	Preocupa?	Medido
Função anônima simples	não	idêntico à nomeada
Closure com 0 allocs/op	não	1,00–1,17×
Closure criada uma vez e reutilizada	não	1,00×
Function value em hot path	só se a função for grande	1,05× aqui, 1,36× com corpo maior
Closure escapando a cada operação	sim	3,20× + 16 B/op
Closure capturando objeto grande	sim	100 MB retidos
Milhões de allocations por segundo	atenção alta	3,34 GB no profile

Checklist

Existe closure?
      ↓
Captura variável?
      ↓
Escapa? ............. gcflags=-m=2
      ↓
Aloca por operação? . benchmark
      ↓
Está em hot path?
      ↓
Aparece no profile? . pprof
      ↓
Só então otimizar

Se travou em qualquer etapa, pare. Não tem otimização ali.

Código da POC

Os 6 benchmarks, os testes que transformam a tabela em asserção, o teste de live heap e o script que roda benchmark + escape analysis + pprof:

git clone <REPO>
cd <PASTA>
./run.sh

Os seus números vão ser diferentes dos meus. Compare as razões.

E se você achar um cenário que contradiz algum destes resultados, me manda nos comentários, eu rodo.

Seu servidor pode estar confiando em certificados falsos. Veja como testar e corrigir.

renanbastos93 — Tue, 03 Nov 2026 17:37:48 +0000

Seu servidor pode estar confiando em certificados falsos. Veja como testar.

Imagine receber uma ligação de alguém que se apresenta como funcionário do seu banco. A pessoa conhece os procedimentos, passa informações convincentes e parece legítima.

Mas é um golpista.

Na internet, algo parecido pode acontecer com os certificados digitais. Eles ajudam seu computador a verificar se um site é realmente quem diz ser.

Foi justamente esse mecanismo de confiança que entrou em risco com o incidente da eMudhra (emSign), divulgado em outubro de 2026.

O que aconteceu?

As chaves privadas de oito certificados intermediários da eMudhra foram comprometidas.

Com essas chaves, um atacante poderia criar certificados aparentemente legítimos para domínios que não controla.

Na prática, isso abre espaço para ataques de man-in-the-middle (MITM), nos quais um criminoso intercepta a comunicação entre você e um serviço.

Isso não significa que seu servidor foi invadido. Significa que ele pode estar confiando em certificados que não deveria.

A solução é atualizar os certificados de confiança e verificar se o sistema passou a rejeitar os comprometidos.

1. Como saber se você está vulnerável?

Os pesquisadores disponibilizaram um endereço para testar essa falha.

No Linux ou macOS, execute:

curl https://dv-g3b-emudhra.we-have-a-problem.com/

Se aparecer:

Your client successfully connected to the site.
That's bad!

Seu curl aceitou a cadeia comprometida. É necessário corrigir.

O resultado esperado em um ambiente corrigido é:

curl: (60) SSL certificate problem

Esse erro é uma boa notícia: significa que o certificado foi rejeitado.

Erros de DNS ou timeout não comprovam que o sistema está protegido.

2. Como corrigir no Linux

Primeiro, descubra qual distribuição está utilizando:

cat /etc/os-release

Para identificar a arquitetura do processador:

uname -m

x86_64: normalmente Intel ou AMD.
aarch64: arquitetura ARM64, como a Orange Pi.

Ubuntu e Debian

Descubra a versão instalada dos certificados:

dpkg-query -W ca-certificates

Confira qual versão está disponível para atualização:

apt-cache policy ca-certificates

Agora atualize:

sudo apt update
sudo apt install --only-upgrade ca-certificates
sudo update-ca-certificates --fresh

Algumas versões corrigidas de referência:

Distribuição	Versão corrigida
Ubuntu 22.04	`20260816ubuntu0.22.04.1`
Ubuntu 24.04	`20260816ubuntu0.24.04.1`
Debian 12	`20250419~deb12u2`
Debian 13	`20250419+deb13u1`

Se o sistema não oferecer uma versão corrigida, revise os repositórios de segurança antes de prosseguir.

3. Como corrigir no macOS

No macOS, existe um detalhe: o curl nativo da Apple pode utilizar certificados diferentes dos utilizados pelo Homebrew.

Descubra qual versão está sendo executada:

which curl
curl --version

Se aparecer /usr/bin/curl, você está utilizando a versão fornecida pela Apple.

Uma alternativa é instalar e atualizar o curl pelo Homebrew:

brew update
brew install ca-certificates curl
brew upgrade ca-certificates curl

Depois, configure o terminal para priorizá-lo:

echo 'export PATH="$(brew --prefix)/opt/curl/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

Confirme:

which curl

O caminho deve apontar para o Homebrew, não para /usr/bin/curl.

Importante: isso não corrige automaticamente o curl nativo da Apple nem outros aplicativos. Eles precisam ser verificados separadamente.

4. Como validar a correção

Execute os dois testes disponibilizados pelos pesquisadores:

for domain in \
  dv-g3b-emudhra.we-have-a-problem.com \
  dv-g3b-aaa-emudhra.we-have-a-problem.com
do
  echo "Testando: $domain"

  curl --noproxy '*' -sS \
    --connect-timeout 10 --max-time 20 \
    "https://$domain/" \
    -o /dev/null \
    -w 'HTTP: %{http_code} | Verify: %{ssl_verify_result}\n'
done

O resultado esperado para ambos é semelhante a:

curl: (60) SSL certificate problem
HTTP: 000 | Verify: 20

Agora confirme que uma conexão HTTPS legítima continua funcionando:

curl -I https://github.com

Uma resposta como HTTP/2 200 confirma que o curl conseguiu estabelecer essa conexão normalmente.

Não utilize curl -k ou --insecure, porque esses parâmetros desabilitam justamente a validação que queremos testar.

5. E os serviços em Docker, Go, Python e Node.js?

Aqui está um detalhe importante: atualizar o sistema operacional não garante que todas as aplicações estejam corrigidas.

Algumas utilizam bibliotecas ou certificados próprios.

Versões corrigidas de referência:

Tecnologia	Versão
Go	1.26.10 ou 1.27.3
Python (`certifi`)	2026.10.19
Node.js 22	22.23.4
Node.js 24	24.22.1
Node.js 26	26.12.1

Para verificar:

go version
node -v
python -m pip show certifi
docker ps

Se estiver utilizando Docker, revise também as imagens-base e os certificados de cada contêiner.

No Go, atualizar a versão instalada não corrige automaticamente os binários já compilados: é necessário recompilá-los com a versão corrigida.

6. O que encontrei nos meus servidores?

Depois de receber o alerta, resolvi verificar três ambientes que utilizo:

Ambiente	Resultado
Orange Pi 5 Max (Ubuntu)	Vulnerável inicialmente; corrigida
VPS Hostinger (Debian)	Vulnerável inicialmente; corrigida
VPS Contabo (Ubuntu)	Já rejeitava os certificados comprometidos

Os três passaram nos testes finais do curl.

O mais interessante é que os servidores estavam funcionando normalmente. Nenhuma falha aparente, nenhum serviço necessariamente parado.

O problema estava na confiança depositada em certificados comprometidos.

Um serviço estar online não significa necessariamente que está seguro.

Conclusão

Segurança não é apenas manter sistemas atualizados. É também testar se as correções realmente funcionaram.

Nesse caso, alguns comandos foram suficientes para encontrar um problema real, aplicar a correção e validar o resultado.

Vale lembrar que os testes apresentados verificam o comportamento do curl. Aplicações com mecanismos próprios de validação TLS precisam ser avaliadas separadamente.

Agradecimentos

Esse artigo nasceu de um alerta compartilhado no Slack pelo meu colega Jefferson Luis Martins (Jeff).

Ele trouxe o contexto do incidente, explicou os riscos e compartilhou orientações para correção, o que me motivou a verificar meus próprios ambientes.

Valeu pelo alerta, Jeff!

Segurança também se constrói compartilhando conhecimento.

Referências

Publicado em outubro de 2026. As versões e recomendações refletem as informações disponíveis na data da publicação.

The Rise of Solution Architects in the Age of Artificial Intelligence

renanbastos93 — Fri, 24 Apr 2026 02:01:41 +0000

Introduction

Based on what I have observed in the technology market, a clear and inevitable shift is taking place. This perspective comes not only from global trends but also from my daily experience building scalable solutions and working with Artificial Intelligence.

We are entering a new era where AI is no longer just a support tool—it is becoming a strategic ally in building products and services. In this scenario, the role of the Solution Architect is gaining prominence, connecting technology, business strategy, and real-world outcomes.

From Code Executors to Solution Engineers

With the rapid advancement of AI, the demand for developers focused solely on task execution is decreasing. This does not mean the end of software development—it means evolution.

Professionals who limit themselves to coding without understanding business context risk being replaced by automation. Meanwhile, the demand for Solution Engineers and Architects continues to grow.

These professionals are expected to:

Understand business rules and strategic goals
Translate requirements into scalable solutions
Leverage AI to enhance productivity
Orchestrate complex systems
Deliver measurable business impact

Technical expertise remains essential, but strategic thinking has become the true differentiator.

The Rise of AI Agents and Intelligent Orchestration

As AI ecosystems evolve, new tools are emerging to manage, govern, and scale intelligent systems. One such concept is the Harness, which represents the ability to orchestrate resources, configure memory, and ensure governance in AI-driven environments.

Rather than being just a tool, Harness embodies a new paradigm in software development, enabling:

AI agent orchestration
Memory configuration and management
Governance and observability
Seamless integrations
Security and operational control

This approach allows organizations to build robust, scalable, and business-aligned solutions.

Business Impact

For companies, this transformation is more than technological—it is strategic. Organizations that adopt AI with governance and vision can:

Increase operational efficiency
Reduce costs
Scale faster
Improve decision-making
Drive innovation

Technology is no longer just a support function—it is a core driver of business value.

Conclusion

In my view, the market is evolving at an unprecedented pace. The future belongs not only to those who can code, but to those who understand business and leverage technology strategically.

We are witnessing the rise of a new generation of professionals—Solution Engineers and Architects—who will orchestrate innovation with the support of Artificial Intelligence.

Tools like Harness symbolize this new era, where intelligence lies not only in code, but in the ability to connect technology, governance, and strategy.

Seu app Go no K8s está usando até 20x mais CPU do que deveria (e como corrigir do jeito certo)

renanbastos93 — Fri, 27 Feb 2026 01:09:31 +0000

Introdução

Esse é um bug extremamente comum em aplicações Go rodando em Kubernetes — inclusive em times experientes.

Os sintomas quase sempre são os mesmos:

CPU alta mesmo com pouco tráfego
latência instável
throttling frequente no pod
autoscaling agressivo sem ganho real de throughput

Na maioria dos casos, o culpado é este aqui:

runtime.NumCPU()

Neste post você vai entender:

Por que NumCPU() é errado em containers
Como o Kubernetes realmente limita CPU
A solução correta (com e sem automaxprocs)
Qual é a boa prática de pool size por core
Quantas goroutines por core fazem sentido na prática

O problema

Muitas libs Go dimensionam concorrência com base em runtime.NumCPU():

worker pools
connection pools
filas
paralelismo interno

Exemplo real:

poolSize := 10 * runtime.NumCPU()

Isso parece razoável fora de containers.

Mas dentro do Kubernetes, isso é um erro sério.

O que runtime.NumCPU() realmente retorna

runtime.NumCPU() não lê o cgroup.

Ele retorna os CPUs visíveis do host, não o limite do container.

Exemplo:

Node com 64 CPUs
Pod com resources.limits.cpu: 500m

Resultado:

runtime.NumCPU() = 64
poolSize = 640 goroutines

Seu pod tem meio core e está tentando rodar 640 goroutines concorrentes.

Resultado:

context switch excessivo
CPU throttling constante
latência imprevisível
performance pior

Como o Kubernetes limita CPU

Quando você define:

resources:
  limits:
    cpu: "500m"

O Kubernetes configura o cgroup:

/sys/fs/cgroup/cpu.max = 50000 100000

Isso significa 0.5 CPU.

O Go runtime não considera isso ao usar NumCPU().

Provando com uma POC

package main

import (
    "fmt"
    "runtime"

    _ "go.uber.org/automaxprocs"
)

func main() {
    fmt.Printf("NumCPU()      = %d\n", runtime.NumCPU())
    fmt.Printf("GOMAXPROCS(0) = %d\n", runtime.GOMAXPROCS(0))
}

Rodando com Docker:

docker run --cpus=0.5 → NumCPU=10  GOMAXPROCS=1
docker run --cpus=1   → NumCPU=10  GOMAXPROCS=1
docker run --cpus=2   → NumCPU=10  GOMAXPROCS=2

Conclusão:

NumCPU() sempre retorna o host
GOMAXPROCS respeita o limit quando configurado corretamente

Regra de ouro

Nunca use runtime.NumCPU() para dimensionar concorrência em containers.

Sempre use runtime.GOMAXPROCS(0).

A solução correta

// errado
poolSize := 10 * runtime.NumCPU()

// correto
poolSize := 10 * runtime.GOMAXPROCS(0)

Go ≤ 1.24 vs Go ≥ 1.25

Go 1.24 e abaixo

Até o Go 1.24, o runtime não era container-aware.

É obrigatório usar:

import _ "go.uber.org/automaxprocs"

Go 1.25+

A partir do Go 1.25:

o runtime já lê o cgroup
GOMAXPROCS é ajustado automaticamente
não precisa mais do automaxprocs

Quantas goroutines por core?

CPU-bound

Regra:

1 goroutine por core

poolSize := runtime.GOMAXPROCS(0)

I/O-bound

Boa prática:

5 a 10 goroutines por core

poolSize := 5 * runtime.GOMAXPROCS(0)

No máximo:

poolSize := 10 * runtime.GOMAXPROCS(0)

Pools de conexão

Boa prática:

2 a 4 conexões por core

maxConns := 2 * runtime.GOMAXPROCS(0)

Comparativo

CPU limit	NumCPU()	GOMAXPROCS	Pool recomendado
500m	10	1	5–10
1000m	10	1	5–10
2000m	10	2	10–20

TL;DR

Nunca use runtime.NumCPU() em containers
Sempre use runtime.GOMAXPROCS(0)
Go ≤ 1.24 → use automaxprocs
Go ≥ 1.25 → não precisa
CPU-bound → 1 goroutine por core
I/O-bound → 5–10 goroutines por core

Código da POC

https://github.com/renanbastos93/numcpu-k8s

Pipeline em Go - Compondo operações de forma elegante e simples

renanbastos93 — Fri, 10 Oct 2025 02:33:47 +0000

Introdução

Recentemente embarcamos em um pequeno projeto interno com o colega Jonas Freire: criar uma forma mais expressiva e limpa de encadear operações em Go. Eu participei ajudando a definir contratos, escrever testes e validar o comportamento do pacote. Em conjunto com a empresa, decidimos abrir esse trabalho como open source, para que outros desenvolvedores também possam usar, contribuir e nos dar feedback.

Esse artigo vai mostrar, de forma simples e prática, como usar o pacote pipeline, seus conceitos básicos e alguns exemplos reais para você começar rapidamente.

Por que usar pipeline?

Em Go, quando você precisa realizar várias transformações ou validações consecutivas, o código costuma ficar assim:

res, err := foo()
if err != nil { return err }
res, err = bar(res)
if err != nil { return err }
res, err = baz(res)
if err != nil { return err }
// ...

Ou, se for uma cadeia de funções, você acaba fazendo algo como:

out := fn3(fn2(fn1(input)))

Isso torna o fluxo difícil de ler e difícil de inserir tratamento de erro de forma padronizada.

O pipeline deste projeto provê um jeito idiomático de criar uma sequência de operações que:

Recebe um valor inicial
Aplica passos (funções) um após o outro
Interrompe a execução no primeiro erro
Retorna o valor final ou o erro ocorrido

Ou seja: deixa o encadeamento linear, evita repetição de checagem de erro e melhora a legibilidade.

Conceitos principais

Aqui estão os conceitos centrais que você precisa entender para usar o pipeline:

Conceito	Descrição
Step[T]	É um tipo de função que representa um passo da pipeline: `func(ctx context.Context, T) (T, error)`
Pipeline[T]	O construtor da sequência de passos, começando com um valor inicial de tipo `T`
New(initial T)	Cria uma nova pipeline com valor inicial
Do(step Step[T])	Adiciona mais um passo à pipeline
Execute() / ExecuteWithContext(ctx)	Executa todos os passos até o fim ou até encontrar erro
ToStep(...)	Função auxiliar que converte funções “normais” (por exemplo `func(T) T` ou `func(T) (T, error)`) para o formato `Step[T]`

O pipeline também incorpora suporte a contexto, para cancelamento ou timeout, e retorna erros enriquecidos com informações como em que passo ocorreu a falha.

Como usar (exemplos práticos)

Exemplo básico com strings

import (
    "context"
    "fmt"
    "strings"

    "github.com/lastro-co/pipeline"
)

func ensureNonEmpty(_ context.Context, s string) (string, error) {
    if s == "" {
        return "", fmt.Errorf("string vazia")
    }
    return s, nil
}

func main() {
    out, err := pipeline.
        New("  ola mundo  ").
        Do(pipeline.ToStep(strings.TrimSpace)).   // converte func(string) string
        Do(pipeline.ToStep(strings.ToUpper)).     // outra função simples
        Do(ensureNonEmpty).                       // função já no formato Step[T]
        Execute()

    if err != nil {
        fmt.Println("Erro:", err)
    } else {
        fmt.Println("Resultado:", out)
    }
}

Aqui estamos compondo 3 passos:

TrimSpace para remover espaços
ToUpper para deixar em maiúsculo
Validar que não ficou vazio

Se em algum passo houver erro (por exemplo valor vazio), a execução para ali e retorna o erro.

Adaptando funções com múltiplos parâmetros

Se você já tiver uma função como:

func add(x, y int) int { return x + y }

Você pode adaptá-la dentro da pipeline usando uma closure:

.Do(func(ctx context.Context, x int) (int, error) {
    return add(x, 5), nil
})

Assim você encapsula a lógica e transforma em um Step[int].

Uso de contexto / timeout

Você pode usar ExecuteWithContext para que a pipeline respeite cancelamento ou timeout:

ctx, cancel := context.WithTimeout(context.Background(), 100 * time.Millisecond)
defer cancel()

result, err := pipeline.
    New("algum valor").
    Do(pipeline.ToStep(strings.ToUpper)).
    Do(slowStep).   // passo que demora
    ExecuteWithContext(ctx)

if err != nil {
    // Por exemplo: context.DeadlineExceeded
    fmt.Println("Falha:", err)
}

Se o contexto for encerrado antes do término, o pipeline interrompe e retorna o erro do contexto.

Erros com contexto de passo

Quando um passo falha, o pacote retorna um erro enriquecido (PipelineError) que contém:

StepIndex: índice do passo que falhou
TotalSteps: número total de passos
OriginalErr: o erro retornado pela função que falhou
LastValue: último valor processado até então

Isso ajuda a depurar exatamente onde a falha ocorreu.

Dicas boas práticas & considerações

Prefira criar passos pequenos, com responsabilidade única.
Use ToStep(...) sempre que possível para converter funções existentes e evitar boilerplate.
Teste cada passo isoladamente para garantir que o comportamento de erro está correto.
Para operações que recebem múltiplos parâmetros, use closures como mostrado acima.
Em casos especiais, você pode usar tipos de erro customizados para identificar falhas específicas e tratá-las de forma distinta após Execute.

Conclusão e convite à comunidade

Esse pacote surgiu como uma iniciativa interna do Jonas (e com minha ajuda nos contratos e testes) e agora está aberto como open source. A ideia é oferecer uma forma elegante e clara de encadear operações em Go, com tratamento automático de erros e suporte a contexto.

Se você gostou e quiser contribuir — seja com sugestões, documentação, exemplos ou novos recursos — fique à vontade para abrir issues, pull requests ou me chamar. Vamos crescer juntos! 🚀

Por que você deve repensar o uso de Regex em validações de strings em Go

renanbastos93 — Sun, 23 Feb 2025 00:05:15 +0000

Quando falamos de validação de strings no Go, uma das soluções mais comuns é o uso de expressões regulares (regex). No entanto, dependendo do contexto, o uso de regex pode ser menos eficiente do que alternativas mais simples. Em sistemas de alta performance, como os que lidam com grandes volumes de dados ou que precisam ser executados em ambientes com recursos limitados, é importante considerar o impacto de cada escolha de implementação.

Embora regex seja uma ferramenta poderosa, sua utilização indiscriminada pode resultar em impactos de performance, principalmente em Go, onde cada operação é otimizada ao máximo para garantir alta eficiência. Neste post, vamos abordar um exemplo simples de validação de strings alfanuméricas, comparando o uso de regex com uma abordagem baseada em Unicode e explicando como otimizar o uso de regex no Go para obter melhores resultados.

O que acontece por trás das cortinas: Regex vs Unicode
A biblioteca regexp é bastante útil, mas pode ser mais lenta do que validações feitas manualmente usando funções da biblioteca unicode. Isso ocorre porque o Go precisa compilar o regex e avaliar sua expressão toda vez que é usado dentro de um método. Isso consome mais tempo de CPU e memória, especialmente em validações simples, como a checagem, se uma string contém apenas caracteres alfanuméricos.

A alternativa, mais eficiente, é iterar sobre a string e validar cada caractere individualmente, utilizando funções como unicode.IsLetter e unicode.IsDigit. Isso evita a sobrecarga de compilar o regex toda vez que a função é chamada e pode ser muito mais rápido para cenários simples.

Exemplo prático: Comparando as abordagens

Aqui está um exemplo em Go para comparar as duas abordagens: uma usando regex e outra utilizando Unicode diretamente.

Implementação com Regex:

var re = regexp.MustCompile(`^[A-Za-z0-9_]+$`)

func isValidWithRegex(s string) bool {
    return re.MatchString(s)
}

Implementação usando Unicode:

func isValid(s string) bool {
    for _, r := range s {
        if !(unicode.IsLetter(r) || unicode.IsDigit(r) || r == '_') {
            return false
        }
    }
    return len(s) > 0 // Garante que a string não está vazia
}

Comparação de Performance

Vamos rodar alguns benchmarks para comparar a performance das duas abordagens.

Benchmark com Unicode:

// BenchmarkTestIsValid-8       18216368            66.18 ns/op        0 B/op          0 allocs/op
func BenchmarkTestIsValid(b *testing.B) {
    for i := 0; i < b.N; i++ {
        isValid("Teste_123")
        isValid("Valido_ABC")
        isValid("Invalido!")
        isValid("12345")
        isValid("")
    }
}

Benchmark com Regex:

// BenchmarkTestIsValidWithRegex-8       3069778           401.3 ns/op         0 B/op          0 allocs/op
func BenchmarkTestIsValidWithRegex(b *testing.B) {
    for i := 0; i < b.N; i++ {
        re.MatchString("Teste_123")
        re.MatchString("Valido_ABC")
        re.MatchString("12345")
        re.MatchString("")
    }
}

Resultados

Como você pode observar nos benchmarks acima, a versão que usa Unicode é significativamente mais rápida do que a versão com regex. A versão com Unicode realiza cerca de 18 milhões de operações por segundo, enquanto a versão com regex realiza apenas cerca de 3 milhões.

Por que isso acontece?

Quando usamos regex, estamos criando e compilando uma expressão regular toda vez que chamamos a função. O processo de compilação e execução da expressão regular envolve mais passos do que simplesmente iterar sobre os caracteres da string com funções do unicode. Isso faz com que a execução com regex consuma mais tempo de CPU e memória.

Quando usar Regex?

Isso não significa que você deve parar de usar regex. Em casos mais complexos, onde você precisa de validações mais sofisticadas, regex pode ser a melhor escolha. No entanto, em validações simples, como a checagem de caracteres alfanuméricos, o uso de Unicode diretamente é muito mais eficiente.

Dica de Performance: Compile Regex fora do método
Se você optar por usar regex, uma boa prática é compilar a expressão regular fora do método, para que ela não precise ser recompilada a cada chamada. Isso pode ajudar a reduzir o custo de performance de usar regex.

var re = regexp.MustCompile(`^[A-Za-z0-9_]+$`)

func isValidWithRegex(s string) bool {
    return re.MatchString(s)
}

Ao compilar a expressão regular uma vez e reutilizá-la, você reduz significativamente o impacto de performance.

Conclusão

Embora regex seja uma ferramenta poderosa e útil, seu uso em validações simples pode ser ineficiente, especialmente quando a performance é uma prioridade. Em Go, alternativas como a utilização da biblioteca unicode podem oferecer ganhos significativos de performance. Se for necessário usar regex, lembre-se de compilar a expressão regular fora do método para otimizar o desempenho.

Agora, repense como você está validando suas strings no seu projeto e escolha a abordagem mais eficiente para o seu caso!

Criando meu pacote de erro usando Go

renanbastos93 — Tue, 02 Jan 2024 19:35:20 +0000

Neste artigo, vamos dar um rolê pela criação de erros usando Golang, ou seja, com sua biblioteca padrão. Depois desse aquecimento, vamos mergulhar no desenvolvimento do nosso próprio pacote.

Se você ainda não está familiarizado ou não manja muito de interfaces em Golang, eu super recomendo dar uma lida nesse artigo antes, porque a coisa vai ficar intensa. Vamos explorar os pacotes padrão e desvendar como podemos usá-los para construir algo incrível. Então, prepara o café e vem comigo nessa jornada pelos segredos dos pacotes em Golang. Bora nessa?

Para começar, vamos explorar duas maneiras simples de criar erros em Golang, utilizando as bibliotecas padrão 'errors' e 'fmt'. Essas são ferramentas poderosas que vão nos permitir adicionar um toque personalizado aos nossos erros e deixar nossa aplicação mais robusta. Vamos lá!

Usando o pacote errors

errors.New("failed operation") // Aqui vai retornar um novo erro com a mensagem `failed operation`

Usando o pacote fmt

fmt.Errorf("failed again") // Aqui vai retornar um novo erro com a mensagem `failed again`

Uma característica fascinante do pacote fmt é a liberdade que ele oferece para personalizar os erros. Além disso, podemos dar um toque especial ao envolvê-los utilizando a referência %w. Vamos dar uma olhada prática nisso com um exemplo:

errOp := fmt.Errorf("failed operation") // Cria um novo erro
errAgain := fmt.Errorf("%w: again", errOp) // Cria um novo erro que obtém como principal o `errOp`

Essa abordagem não apenas permite personalizar os erros, mas também oferece uma maneira inteligente de repassar informações sem a necessidade de fazer log em cada camada do código. Ao herdar o erro anterior e manter a mesma raiz, conseguimos construir um rastreamento completo do erro, proporcionando uma visão clara da jornada do problema. Uma técnica que não só simplifica, mas também enriquece o processo de identificação e resolução de falhas em nosso código.

Agora, acredito que estamos prontos para dar o próximo passo e criar nosso próprio pacote, respeitando a interface error e aproveitando as funcionalidades do pacote padrão error. Bora lá!

Para iniciar essa jornada incrível, vamos criar uma estrutura personalizada. Vamos seguir a ideia de ter um erro com um código e uma mensagem, algo semelhante aos erros que encontramos no dia a dia das APIs REST. Essa abordagem não apenas facilita a identificação e tratamento de erros, mas também adiciona uma camada de clareza ao nosso código. Vamos colocar a mão na massa e ver o que conseguimos construir juntos!

type myError struct {
    code int
    msg  string
}

Agora que temos nossa struct para representar erros personalizados na aplicação, o próximo passo é criar um método que não apenas instancie o erro, mas também retorne uma interface error. Dessa forma, nossa aplicação pode integrar suavemente esses erros personalizados ao fluxo padrão de manipulação de erros em Golang. Vamos criar esse método e garantir que nossos erros sejam facilmente utilizáveis!

func NewError(code int, msg string) error {
    return &myError{
        code: code,
        msg:  msg,
    }
}

Vale destacar um ponto crucial que frequentemente é negligenciado e resulta em retrabalho desnecessário: muitas pessoas cometem o equívoco de retornar diretamente o ponteiro da estrutura na assinatura do método, em vez da interface error. Essa prática pode gerar complicações adicionais durante validações e manipulação de erros.

Para concluir nosso contrato, vamos adicionar um método Error() string. Esse método é essencial, pois atende ao contrato definido pela interface error, garantindo que nossos erros personalizados possam ser facilmente integrados e utilizados em qualquer contexto que espera uma implementação da interface error. Vamos fortalecer a base do nosso pacote, deixando-o ainda mais robusto e eficiente.

func (e myError) Error() string {
    return fmt.Sprintf("%d: %s", e.code, e.msg)
}

Caramba, pessoal, não é que nosso pacote está pronto? E que tal irmos além e testarmos isso na prática? Vamos fazer um teste repassando nosso erro para frente, utilizando a técnica de wrap com outro erro, e em seguida, validar se o tipo do erro foi herdado corretamente. Ah, vai ser legal! Vamos lá, é hora de entrar nesse teste e garantir que nosso pacote está afiado. Go go go!

// Criando um erro bad request
err := NewError(400, "bad request")

// Envelopando o erro not found dentro do bad request
errAgain := fmt.Errorf("%w: %v", err, NewError(404, "not found"))

// output:
// 400: bad request: 404: not found
fmt.Println(errAgain)

// Aqui estamos validando se o errAgain é herdado do bad request
// output
// true
fmt.Println(errors.Is(errAgain, err))
// Aqui a gente remove o errAgain e pega somente o original
// output
// 400: bad request
fmt.Println(errors.Unwrap(errAgain))

Em conclusão, a valorização e aplicação adequada das interfaces nativas do Go, com destaque para a interface error, revelam-se cruciais. Ao respeitar esses padrões, não apenas fortalecemos a consistência do código, mas também habilitamos rastreamentos mais eficientes quando necessários. Essa abordagem não apenas eleva a qualidade do código, mas também promove a reutilização, consolidando a robustez e flexibilidade no desenvolvimento em Go. Vamos adotar esses princípios para aprimorar continuamente nossa prática de programação em Go.

Para ver o código completo, acesse aqui!

Como Fazer Restore do MongoDB usando mongorestore com Arquivos wiredTriger

renanbastos93 — Sun, 03 Dec 2023 18:13:57 +0000

Introdução

E aí, pessoal! Sejam todos bem-vindos a este guia prático de como realizar a restauração de um backup no MongoDB usando a ferramenta mongorestore. Mas peraí, aqui tem um toque especial – estamos falando de uma restauração com a ausência dos arquivos padrão .bson e a presença dos misteriosos arquivos .wt, também conhecidos como WiredTiger. Vamos desbravar esse terreno e entender como essa peculiaridade pode proporcionar uma compreensão ainda maior do processo. Bora lá! 🚀

Contexto e ferramentas

Para começar esta jornada, gostaria de compartilhar que recebi esse dump do time de SRE para realizar uma restauração em outro ambiente, simulando assim um cenário real. Curiosamente, a base de dados na época tinha 8GB. Então, vamos lá! Para iniciar, precisamos instalar as ferramentas do MongoDB.

$ brew install mongodb-database-tools

Agora, dispomos de algumas ferramentas úteis para interagir com o MongoDB, como o mongodump e o mongorestore. Neste tutorial, concentraremos nossa atenção no workaround utilizando o mongorestore para lidar com o cenário específico em que possuímos apenas os arquivos WiredTiger.

Visualizando os erros

Bom, quais foram os erros que ocorreram ao tentar utilizar o mongorestore? Na verdade, tive apenas dois erros e tentei diversos workarounds que não obtiveram sucesso. Vamos analisar o comando e o respectivo output.

$ mongorestore --username adminuser --password password123 mongodb://127.0.0.1:27017 --gzip dump.tar.gz
# 2023-11-30T11:26:18.319-0300  Failed: file dump.tar.gz does not have .bson extension

# Outra tentativa

$ mongorestore --username adminuser --password password123 mongodb://127.0.0.1:27017 --dir restore-656867ceae3af1227ffa3f59/
# 2023-11-30T11:28:10.196-0300  preparing collections to restore from
# 2023-11-30T11:28:10.199-0300  don't know what to do 
# ...
# 2023-11-30T11:28:10.201-0300  0 document(s) restored successfully. 0 document(s) failed to restore.

Percebemos que, neste caso, não foi possível realizar a restauração conforme o esperado. No entanto, este era o único dump disponível. Diante desse desafio, iniciei uma pesquisa extensiva, explorando várias alternativas em documentações e workarounds. Agora, vamos examinar uma solução que se mostrou eficaz para o meu cenário. Reconheço que pode haver métodos mais simples e precisos, então se alguém tiver alguma sugestão, não hesite em compartilhar nos comentários. Vamos lá!

Pensando na solução e executando

É interessante mencionar que você pode tanto configurar o MongoDB localmente quanto utilizar uma imagem Docker. Pessoalmente, optei por utilizar uma imagem Docker, mas para facilitar o entendimento, vou demonstrar como configurar um MongoDB local sem o uso do Docker.

Se o MongoDB ainda não estiver instalado em sua máquina, basta realizar a instalação da maneira que for mais conveniente para você. Em seguida, subiremos o servidor via linha de comando utilizando o comando mongod e especificando o caminho para o nosso dump.

$ mongod --dbpath ~/dump

Agora, podemos observar que ele conseguiu identificar os arquivos do WiredTiger. Ou seja, o que precisamos fazer agora é gerar um dump desta base que nos forneça os arquivos BSON. Esses arquivos são essenciais para serem utilizados na restauração do nosso ambiente.
Vamos executar o comando:

$ mongodump --host 127.0.0.1 -u myuser -p mypass -d mydatabase --port 27017 --out newDump --authenticationDatabase=admin

Beleza, galera! Agora temos um dump novinho em folha com os arquivos BSON. Uhull! E agora, partiu fazer o restore? 🚀

$ mongorestore --verbose --username adminuser --password password123 mongodb://127.0.0.1:27017 newDump

# 2023-12-01T11:19:17.148-0300  [###.....................]  mydatabase.Collection  1.26GB/8.03GB  (15.7%)
# 2023-12-01T11:19:17.148-0300  [#######################.]     mydatabase.Collection  2.95GB/2.96GB  (99.5%)
# 2023-12-01T11:19:17.148-0300  
# 2023-12-01T11:19:18.878-0300  [########################]  mydatabase.Collection  2.96GB/2.96GB  (100.0%)

Conclusão

Encerrando nossa odisséia pelo universo MongoDB, superamos perrengues, desbravamos soluções e agora brindamos a um novo dump com arquivos BSON. Uhull! Estamos prontos para restaurar e esse processo, embora não seja a única trilha, certamente clareia o caminho para quem encara dilemas similares. Se tiver truques ou dicas na manga, bota aí nos comentários. Juntos, fortalecemos a rede de conhecimento, inspirando novas explorações. Na jornada do aprendizado, cada desafio é um convite para avançar. Até a próxima aventura, exploradores digitais! 🌟🚀

Qual a diferença de usar um receiver com ou sem ponteiro em Go?

renanbastos93 — Mon, 25 Sep 2023 12:52:41 +0000

Recentemente, tive a incrível oportunidade de participar de um dos maiores eventos de Golang da América Latina, a Gophercon BR. Gostaria de expressar minha gratidão aos organizadores e a todos que estiveram presentes no evento, pois proporcionaram um ambiente incrível para networking e aprendizado.

Durante o evento, tive um encontro interessante com um rapaz chamado João Salvador. Ele apresentou um desafio intrigante, exibindo um código que imediatamente despertou minha curiosidade e fez meus neurônios entrarem em ação para decifrá-lo. A experiência de resolver esse desafio foi estimulante e educativa, e, após concluí-lo, senti a necessidade de compartilhar esse conhecimento com a comunidade.

Neste post, estou entusiasmado em apresentar o desafio proposto por João Salvador e explicar os detalhes por trás dele. Acredito que a compreensão deste desafio trará uma nova perspectiva sobre o uso de receivers com ou sem ponteiro em Go, proporcionando insights valiosos que podem expandir nossos horizontes e ajudar muitas pessoas a aprofundar seu entendimento da linguagem.

Desafio que me foi Apresentado no Evento

O que você espera que o console imprima? Pense bem antes de continuar lendo, isso vai enriquecer ainda mais sua compreensão no tópico em questão

Comente a sua resposta!

Agora iremos juntos entender e desvendar a solução

Vamos começar nossa jornada entendendo que temos uma estrutura chamada "Person". Cada instância dessa estrutura possui um atributo chamado "Name", que armazena o nome de uma pessoa. Além disso, esta estrutura é enriquecida com um método chamado "SayHi", que é acionado por meio de um conceito conhecido como "receiver". A função principal deste método é simples, ele imprime na tela uma saudação, "Hi", seguida pelo nome da pessoa.

// Declarada a estrutura Person
type Person struct {
    Name string
}

// SayHi vai printar uma saudação Hi seguida com o nome da pessoa
func (e Person) SayHi() {
    fmt.Printf("Hi %s!\n", e.Name)
}

Tá! Mas o que é receiver?

É um parâmetro especial em um método de um tipo definido pelo usuário (struct) que permite que esse método seja chamado em instâncias desse tipo. O receiver é semelhante ao conceito de um objeto em orientação a objetos, mas é específico para métodos em Go.

Observamos que o método SayHi utiliza um receiver de valor, o que significa que, nesse contexto, o método atua em uma cópia do valor original do tipo. Isso implica que qualquer alteração efetuada dentro do método não terá efeito sobre a instância original desse tipo.

Agora que entendemos isso vamos ver como funciona um receiver de ponteiro. Ou seja, o método opera diretamente na instância original do tipo, pois recebe um ponteiro para ela. Isso permite que o método modifique o valor da instância original.

func (p *Person) UpdateName(newName string) {
    p.Name = newName
}

Agora que entendemos ambos os casos comentado a cima, vamos criar nossa func main() para visualizar e entender os outputs gerados.

func main() {
    var p = Person{Name: "Renan"}
    defer p.SayHi()              // Output: Hi Renan!
    defer func() { p.SayHi() }() // Output: Hi Renan Bastos!

    p.UpdateName("Renan Bastos")
}

Parece bruxaria mas não é, os dois defer imprimiram valores diferentes porque o defer empilha uma cópia da estrutura no primeiro e uma função anônima no segundo. Portanto, quando o defer é executado, ele já capturou a alteração no campo Name. O defer funciona como uma pilha, executando o último defer chamado primeiro e desempilhando conforme cada um é executado.

// Output final
// Output: Hi Renan Bastos!
// Output: Hi Renan!

Conclusão

Neste artigo, exploramos o conceito de receiver em Go e a utilidade do defer. Uma questão frequente é quando devemos optar por usar um receiver de ponteiro. A escolha depende das necessidades específicas de seu programa e do comportamento desejado, e não existe uma resposta única. Portanto, a melhor abordagem é avaliar cuidadosamente o contexto de seu código e escolher entre receiver de valor ou de ponteiro com base nas exigências do projeto.

Criando um JSON Unmarshal personalizado em Go

renanbastos93 — Wed, 13 Sep 2023 11:58:54 +0000

Neste breve tutorial, vamos explorar como criar um método UnmarshalJSON personalizado em Go, adaptando-o para uma situação em que temos um campo específico na estrutura que pode ser representado como número, booleano ou string. Isto nos permitirá lidar com dados JSON de forma flexível e personalizada.

Vamos prosseguir com um exemplo prático usando a estrutura "King" com os campos "Active" e "Name". Vamos começar a criar o método UnmarshalJSON personalizado para lidar com o campo "Active" que pode ser representado como número, booleano ou string.

type King struct {
    Name   string `json:"name"`
    Active bool   `json:"active,string"`
}
//Após criar a estrutura vamos implementar a função para o UnmarshalJSON personalizado.

func (k *King) UnmarshalJSON(data []byte) (err error) {
    // Criamos um mapa dinâmico para armazenar os campos JSON.
    var fields map[string]interface{}

    // Realizamos a decodificação JSON padrão no mapa "fields".
    err = json.Unmarshal(data, &fields)
    if err != nil {
        return err
    }

    // Copiamos o valor do campo "name" do mapa para a estrutura "King".
    k.Name = fields["name"].(string)

    // Convertendo o valor do campo "active" para booleano.
    // Usamos `fmt.Sprintf` para garantir que o valor seja uma string antes da conversão.
    activeStr := fmt.Sprintf("%v", fields["active"])

    // Aqui estamos convertendo para boleano e ignoramos o erro pois se vier algo diferente do esperado sempre será falso
    k.Active, _ = strconv.ParseBool(activeStr)

    return nil
}

Agora que entendemos como criar um Unmarshal JSON personalizado, vamos aplicar isso na função principal, chamada 'main', do pacote principal. A seguir, apresentamos o código com os resultados esperados.

func main() {
    var k King
    if err := json.Unmarshal([]byte(`{"active": 1, "name":"renan"}`), &k); err != nil {
        panic(err)
    }
    fmt.Printf("%+v\n", k)
    // Output: {Name:renan Active:true}
}

Para concluir, demonstraremos um teste unitário usando nosso método personalizado, abrangendo todos os casos para uma compreensão abrangente.


func TestKing_UnmarshalJSON(t *testing.T) {
    tests := []struct {
        name    string
        king    King
        data    []byte
        wantErr bool
    }{
        {
            name:    "Employing the number 1 to denote a true value.",
            king:    King{Name: "renan", Active: true},
            data:    []byte(`{"active": 1, "name":"renan"}`),
            wantErr: false,
        },
        {
            name:    "Employing the number 0 to denote a false value.",
            king:    King{Name: "renan", Active: false},
            data:    []byte(`{"active": 0, "name":"renan"}`),
            wantErr: false,
        },
        {
            name:    "Utilizing the string '1' to represent the boolean value 'true'.",
            king:    King{Name: "renan", Active: true},
            data:    []byte(`{"active": "1", "name":"renan"}`),
            wantErr: false,
        },
        {
            name:    "Utilizing the string '0' to represent the boolean value 'false'.",
            king:    King{Name: "renan", Active: false},
            data:    []byte(`{"active": "0", "name":"renan"}`),
            wantErr: false,
        },
        {
            name:    "Utilizing the string 'true' to represent the boolean value 'true'",
            king:    King{Name: "renan", Active: true},
            data:    []byte(`{"active": "true", "name":"renan"}`),
            wantErr: false,
        },
        {
            name:    "Utilizing the bool true to represent the boolean value 'true'",
            king:    King{Name: "renan", Active: true},
            data:    []byte(`{"active": true, "name":"renan"}`),
            wantErr: false,
        },
        {
            name:    "Utilizing the bool false to represent the boolean value 'false'",
            king:    King{Name: "renan", Active: false},
            data:    []byte(`{"active": false, "name":"renan"}`),
            wantErr: false,
        },
        {
            name:    "Utilizing the string 'false' to represent the boolean value 'false'",
            king:    King{Name: "renan", Active: false},
            data:    []byte(`{"active": "false", "name":"renan"}`),
            wantErr: false,
        },
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            var k King
            err := json.Unmarshal(tt.data, &k)
            if (err != nil) != tt.wantErr {
                t.Errorf("King.UnmarshalJSON() error = %v, wantErr %v", err, tt.wantErr)
            }
            if k.Active != tt.king.Active || k.Name != tt.king.Name {
                t.Errorf("unmarshal failed: k[%+v]; tt.kink[%+v];", k, tt.king)
            }
        })
    }
}

Agradeço por acompanhar este tutorial. Se você tiver alguma dúvida, comentário ou sugestão, por favor, não hesite em entrar em contato comigo. Estou à disposição para ajudar e melhorar.

Boneless: a CLI to create your apps with Go

renanbastos93 — Wed, 28 Jun 2023 16:48:43 +0000

Boneless is a powerful tool that offers a wide range of features to facilitate application development. In this blog post, we will explore some essential tools that can be used in conjunction with Boneless: Service Weaver, Go Migrate, SQLC, and Fiber. Let's discover how these tools can boost productivity and efficiency in application development.

After setting the context and providing a comprehensive introduction, we will demonstrate how to use our CLI. First, we need to install the necessary CLI tools.

By the way, first, we need to install the binary of Service Weaver, Go Migrate, SQLC, and Boneless. Even so, I suggest you read the documentation of all of them on your official websites.

$ go install -tags 'mysql sqlite3' github.com/golang-migrate/migrate/v4/cmd/migrate@latest
$ go install github.com/sqlc-dev/sqlc/cmd/sqlc@latest
$ go install github.com/ServiceWeaver/weaver/cmd/weaver@latest
$ go install github.com/renanbastos93/boneless/cmd/boneless@latest

Well, let's go on an adventure

Create scratch project

Always remember to check the available methods by executing boneless help. After that, we can proceed to create a new folder and a go.mod file.

$ mkdir -p myapp
$ cd myapp
$ go mod tidy myapp

# "Now we can start utilizing commands from Boneless
$ boneless create-scratch

After creating the project, we can go ahead and execute it.

$ SERVICEWEAVER_CONFIG="./weaver.toml" boneless run

Adding a New app

If you want to add a new component to your application built with Boneless, the process is straightforward. Here are the steps you can follow

$ boneless create-app user

After that, you need to make changes according to your requirements.

In addition, there are other Boneless commands available that you can use when they are truly necessary. See below:

$ boneless help
Usage: boneless [target]

Targets:
  help                                     Show commands for use
  version                                  Show version
  new  <sql|sqlite3>                       Create a project from scratch using Weaver, SQLC, and go-migrate
  create-scratch <sql|sqlite3>             Create a project from scratch using Weaver, SQLC, and go-migrate
  build                                    Build the Weaver component with SQLC
  make-migrate <app-name> <name>           Create a new migration for an app
  migrate <app-name> <up|down>             Run migrations for an app
  create-app <app-name>                    Create a new app based on a template
  build-app <app-name>                     Build an app using Weaver and SQLC
  run                                      Run the project using Weaver

Parameters:
  <app-name>                               Name of the app to create or run migrations on
  <name>                                   Name of the migration to create
  <up|down>                                Specify "up" to apply migrations or "down" to rollback migrations
  <sql|sqlite>                             Specify "sql" to use some SQL "sqlite3" to use sqlite3 and it is the default

Examples:
  boneless help
  boneless version
  boneless create-scratch
  boneless build
  boneless make-migrate my-app migration-name
  boneless migrate my-app up
  boneless create-app my-app
  boneless build-app my-app
  boneless run

Conclusion

In summary, we have explored the powerful tools available for application development using Boneless. We discussed the Command Line Interface (CLI) that facilitates the creation of web applications, along with Service Weaver, Go Migrate, SQLC, and Fiber. These tools provide essential features to boost productivity and efficiency in developing distributed applications, managing database migrations, generating secure code, and building fast web applications.

By utilizing these tools together, developers have a wide range of resources at their disposal to create robust, scalable, and secure applications. Through the Boneless CLI, you can initiate projects, manage database migrations, and leverage the benefits of Service Weaver and Fiber to build efficient and responsive APIs.

We hope this article has provided a comprehensive overview of these tools and sparked your interest in further exploring the potential of Boneless and its components. With the right combination of tools and knowledge, you will be well-positioned to develop high-quality web applications.

How to verify if the context has a deadline

renanbastos93 — Tue, 31 Jan 2023 01:17:01 +0000

It's very simple, context.Context has a little method called Deadline that returns (deadline time.Time, ok bool). When the ok variable is true, the deadline is set. Why use a deadline? We need to use it to set a time to cancel the operation, e.g. we need to wait for max 3 seconds to execute a query on the database, in case overtakes the time, context will call cancel in the operation.

See the example below:

func something(ctx context.Context) (context.Context, context.CancelFunc) {
    if _, hasDeadline := ctx.Deadline(); !hasDeadline {
        return context.WithTimeout(ctx, time.Minute)
    }
    return context.WithCancel(ctx)
}

Now, let's see an example using this method in an operation that prints a message many times.

func usingSomething() {
    ctx, cancel := something(context.Background())
    defer cancel()

    for {
        select {
        case <-ctx.Done():
            return
        default:
            fmt.Println("something message!")
            time.Sleep(time.Second)
        }
    }
}

Well, I believe that it’s interesting to share the unit test as well.

func TestSomethingWithDeadline(t *testing.T) {
    t.Run("using timeout of 1s", func(t *testing.T) {
        ctx, _ := context.WithTimeout(context.Background(), time.Second)
        ctx, cancel := something(ctx)
        defer cancel()
        _, hasDeadline := ctx.Deadline()
        assert.EqualValues(t, true, hasDeadline)
    })
}

func TestSomethingWithoutDeadline(t *testing.T) {
    t.Run("using default timeout of something method", func(t *testing.T) {
        ctx, cancel := something(context.Background())
        defer cancel()
        _, hasDeadline := ctx.Deadline()
        assert.EqualValues(t, true, hasDeadline)
    })
}

That's what I wanted to show here. I hope this helps!