DEV Community: Jose Luis da Cruz Junior

[pt-BR] Lifetimes em Rust: Desvendando o Tempo de Vida das Variáveis para Pythonistas

Jose Luis da Cruz Junior — Tue, 29 Sep 2026 11:00:00 +0000

Por @zejuniortdr em Abr 16, 2026

Introdução: O Tempo de Vida das Variáveis

Em Python, você nunca precisa se preocupar explicitamente com quanto tempo uma variável vai existir na memória. O garbage collector cuida de tudo automaticamente. Mas em Rust, entender lifetimes (tempos de vida) é essencial para escrever código seguro e eficiente sem um coletor de lixo.

Imagine que você está organizando uma festa:

Em Python: Os convidados (objetos) podem chegar e sair quando quiserem, e um funcionário (garbage collector) limpa tudo depois
Em Rust: Você precisa planejar exatamente quando cada convidado chega e sai, garantindo que ninguém fique esperando por quem já foi embora

Em Rust, o compilador verifica que todos os convidados saíram antes de desmontar a mesa onde estavam — prevenindo o famoso erro de use-after-free sem precisar de um garbage collector.

Seção 1: O Problema que Lifetimes Resolvem

Referências e Borrowing

Em Rust, o sistema de ownership garante segurança na memória, mas e quando queremos compartilhar acesso sem transferir posse?

fn main() {
    let texto = String::from("Olá Rust");  // Dono do valor

    // Referência imutável (borrowing)
    let referencia = &texto;  // "Eu só quero ler, prometo!"

    println!("{}", referencia);
}

O exemplo Python equivalente parece inofensivo nesse caso simples, mas Python não impede padrões realmente perigosos:

# Caso simples: funciona em ambas as linguagens
def main():
    texto = "Olá Python"
    referencia = texto  # Na verdade é a mesma referência
    print(referencia)

# Caso perigoso: Python permite, Rust proibiria em tempo de compilação
def obter_referencia():
    x = [1, 2, 3]
    return lambda: x[0]  # Closure captura referência a x local

f = obter_referencia()
print(f())  # Funciona em Python (GC mantém x vivo), seria erro em Rust

O problema surge quando o dono desaparece antes da referência:

// ERRO DE COMPILAÇÃO:
// expected named lifetime parameter
// O compilador não aceita &String sem lifetime; com 'static seria
// necessário que `s` vivesse para sempre — impossível para uma local!
fn cria_referencia() -> &String {
    let s = String::from("ops!");
    &s  // ERRO: s será destruída no fim da função!
}

Seção 2: Anotação de Lifetimes na Prática

Sintaxe Básica

Lifetimes são anotadas com apóstrofos: 'a. Veja um exemplo funcional:

fn maior<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

fn main() {
    let string1 = String::from("abc");
    let string2 = "xyz";

    let resultado = maior(&string1, string2);
    println!("A maior string é {}", resultado);
}

Lifetimes em Estruturas

Quando uma struct contém referências:

struct Exemplo<'a> {
    parte: &'a str,
}

impl<'a> Exemplo<'a> {
    fn novo(texto: &'a str) -> Exemplo<'a> {
        Exemplo { parte: texto }
    }

    fn pegar_parte(&self) -> &str {
        self.parte
    }
}

Seção 3: Python vs Rust - Gerenciamento de Memória

Como Python Gerencia Tempo de Vida

Python usa contagem de referências e garbage collector:

def exemplo():
    x = [1, 2, 3]  # Objeto criado
    y = x          # Referência compartilhada
    return y       # x é destruído? Depende!

resultado = exemplo()
print(resultado)  # Funciona - GC mantém vivo

# Referência circular: Python lida com isso, mas pode causar vazamentos
import gc
class No:
    def __init__(self):
        self.proximo = None

a = No()
b = No()
a.proximo = b  # a referencia b
b.proximo = a  # b referencia a — ciclo!
del a, b       # GC eventualmente coleta; em Rust, ciclos assim exigem Rc<RefCell<>>
gc.collect()

Rust: Controle Explícito

Em Rust, você precisa garantir manualmente que as referências sejam válidas:

fn exemplo() -> &Vec<i32> {  // ERRO: falta lifetime
    let x = vec![1, 2, 3];
    &x  // x morre aqui!
}

Caso Prático: Construindo um Parser Seguro

Vamos implementar um parser simples que extrai tags de um texto:

struct TagParser<'a> {
    texto: &'a str,
    tag: &'a str,
}

impl<'a> TagParser<'a> {
    fn novo(texto: &'a str, tag: &'a str) -> Self {
        TagParser { texto, tag }
    }

    fn encontrar(&self) -> Option<&'a str> {
        let inicio = format!("<{}>", self.tag);
        let fim = format!("</{}>", self.tag);

        // Usando `restante` para evitar índices inválidos:
        // buscar `fim` a partir do início do texto retornaria
        // o índice errado caso haja tags aninhadas ou repetidas.
        self.texto.find(&inicio).and_then(|start| {
            let restante = &self.texto[start + inicio.len()..];
            restante.find(&fim).map(|end| {
                &restante[..end]
            })
        })
    }
}

fn main() {
    let html = "<div>Conteúdo importante</div>";
    let parser = TagParser::novo(html, "div");

    if let Some(conteudo) = parser.encontrar() {
        println!("Conteúdo: {}", conteudo);
    }
}

Lifetime Elision e Múltiplos Lifetimes

O compilador Rust aplica lifetime elision rules para omitir anotações óbvias, tornando o código menos verboso:

// Com elision (o compilador infere os lifetimes automaticamente)
fn primeira_palavra(s: &str) -> &str {
    s.split_whitespace().next().unwrap_or("")
}

// Equivalente explícito
fn primeira_palavra_explicita<'a>(s: &'a str) -> &'a str {
    s.split_whitespace().next().unwrap_or("")
}

Quando há múltiplos lifetimes, você controla relações entre entradas e saída:

// O retorno vive pelo menos enquanto `x` — independentemente de `y`
fn escolhe_primeiro<'a, 'b>(x: &'a str, _y: &'b str) -> &'a str {
    x
}

Lifetimes em traits também são comuns ao definir abstrações sobre referências:

trait Resumivel<'a> {
    fn resumo(&'a self) -> &'a str;
}

Erros Comuns para Pythonistas

1. Esquecer de anotar lifetimes em funções que retornam referências

Sempre que uma função retorna uma referência derivada de um parâmetro, o compilador precisa saber qual parâmetro "empresta" o dado.

2. Tentar retornar referência para valor local

Este é o erro mais frequente para quem vem do Python — retornar um ponteiro para algo que vai ser destruído ao sair do escopo da função:

// ERRO: `s` não vive o suficiente
fn problema_comum() -> &str {
    let s = String::from("ops");
    &s  // s é destruída aqui; o ponteiro ficaria inválido
}

// CORREÇÃO: retornar o valor com ownership, não uma referência
fn solucao() -> String {
    String::from("ops")
}

3. Subestimar o escopo de variáveis emprestadas

Em Rust, o borrow checker rastreia exatamente onde cada referência pode ser usada — usar uma referência fora do escopo do dono é erro de compilação.

4. Confundir ownership com borrowing em estruturas

Structs que armazenam referências precisam de parâmetros de lifetime; structs que armazenam valores com ownership não precisam.

5. Ignorar lifetime elision

O compilador infere lifetimes simples automaticamente, mas casos com múltiplas referências ou structs exigem anotação explícita. Quando em dúvida, anote.

6. Não usar lifetimes em enums com referências

Enums também podem conter referências e precisam declarar seus lifetimes, assim como structs:

// Sem lifetime: erro de compilação se a variante carregar uma referência
enum Resultado<'a> {
    Ok(&'a str),    // referência com lifetime vinculado ao enum
    Erro(String),   // String com ownership — não precisa de lifetime
}

fn processar<'a>(texto: &'a str) -> Resultado<'a> {
    if texto.is_empty() {
        Resultado::Erro(String::from("texto vazio"))
    } else {
        Resultado::Ok(texto)
    }
}

O Que Aprendemos

Lifetimes garantem que referências sejam sempre válidas
Em Rust, você controla explicitamente o tempo de vida das variáveis
Anotações 'a ajudam o compilador a verificar sua lógica
Python abstrai isso com garbage collector, mas com custo de performance e sem garantias em tempo de compilação
Estruturas com referências precisam declarar seus lifetimes
Lifetime elision simplifica casos comuns; múltiplos lifetimes lidam com relações complexas

Python vs Rust: resumo da abordagem de memória

Aspecto	Python (GC)	Rust (Lifetimes)
Gerenciamento	Automático via garbage collector	Explícito via borrow checker
Segurança	Verificada em tempo de execução	Verificada em tempo de compilação
Conveniência	✅ Alta — sem anotações	⚠️ Média — curva de aprendizado inicial
Previsibilidade	⚠️ Pausas de GC possíveis	✅ Alta — sem GC, sem pausas
Performance	⚠️ Overhead do GC	✅ Zero-cost abstractions
Erros de memória	Detectados em runtime (ou silencosos)	Impossíveis — garantidos em compilação

Quer dominar Rust como um verdadeiro desbravador? Adquira já o livro completo em desbravandorust.com.br e transforme-se em um expert na linguagem que está revolucionando a programação de sistemas!

[pt-BR] Desvendando Iteradores e Closures em Rust: A Potência Funcional para Pythonistas

Jose Luis da Cruz Junior — Tue, 22 Sep 2026 11:00:00 +0000

Por @zejuniortdr em Abr 04, 2026

Se você vem do Python e está começando sua jornada em Rust, provavelmente já percebeu que ambas as linguagens possuem recursos poderosos para programação funcional. No entanto, as semelhanças superficiais escondem diferenças profundas que são cruciais para entender como Rust oferece segurança de memória e desempenho superior.

Neste artigo, vamos explorar como closures e iteradores funcionam em Rust, comparando constantemente com as abordagens do Python. Você descobrirá como Rust implementa esses conceitos de forma única, proporcionando tanto flexibilidade quanto segurança em tempo de compilação.

Por Que Closures e Iteradores São Fundamentais?

Tanto em Python quanto em Rust, closures e iteradores são pilares da programação funcional. Eles permitem:

Escrever código mais conciso e expressivo
Manipular coleções de dados de forma elegante
Criar abstrações poderosas com pouco código

Mas enquanto Python prioriza flexibilidade e legibilidade, Rust adiciona uma camada de segurança e eficiência que previne erros comuns em tempo de compilação.

Vamos começar nossa jornada entendendo as closures, uma das construções mais interessantes em Rust!

Seção 1: Entendendo Closures em Rust

O Que São Closures?

Closures são funções anônimas que podem capturar variáveis do seu ambiente circundante. Se você já usou lambda em Python, já trabalhou com closures!

Python:

# Closure simples em Python
def multiplicador_por(n):
    def multiplicador(x):
        return x * n
    return multiplicador

dobro = multiplicador_por(2)
print(dobro(5))  # Output: 10

Rust:

// Closure simples em Rust com tipos explícitos
fn multiplicador_por(n: i32) -> impl Fn(i32) -> i32 {
    move |x| x * n
}

fn main() {
    let dobro = multiplicador_por(2);
    println!("{}", dobro(5));  // Output: 10
}

Nota sobre impl Fn: Em Rust, ao retornar uma closure de uma função, usamos impl Fn(...) para indicar o tipo de retorno. Isso é mais eficiente que Box<dyn Fn(...)> pois não exige alocação no heap. A palavra-chave move faz a closure adquirir posse (ownership) da variável n, garantindo que ela permaneça válida mesmo após a função retornar.

Ownership em poucas palavras: Rust tem um sistema único onde cada valor tem um único "dono". Quando usamos move, transferimos a posse da variável para dentro da closure — isso é fundamental para garantir segurança de memória sem garbage collector!

Os Três Traits de Closures: Fn, FnMut e FnOnce

Em Rust, traits são interfaces que definem comportamentos. Para closures, existem três traits que determinam como elas interagem com as variáveis capturadas:

Fn: Apenas empresta variáveis (read-only) — pode ser chamada várias vezes
FnMut: Empresta variáveis mutavelmente — pode modificá-las a cada chamada
FnOnce: Adquire posse das variáveis — pode ser chamada apenas uma vez

Vamos ver exemplos práticos:

fn main() {
    let valor = 10;

    // Fn: apenas empresta 'valor'
    let closure_fn = || println!("Valor: {}", valor);
    closure_fn();
    closure_fn();  // Pode ser chamada múltiplas vezes

    // FnMut: empresta 'valor' mutavelmente
    let mut valor_mut = 10;
    let mut closure_fnmut = || {
        valor_mut += 1;
        println!("Valor mut: {}", valor_mut);
    };
    closure_fnmut();
    closure_fnmut();

    // FnOnce: adquire posse de 'valor_once'
    let valor_once = String::from("Hello");
    let closure_fnonce = move || {
        println!("Valor: {}", valor_once);
        // valor_once é consumido aqui (drop ao final da closure)
    };
    closure_fnonce();
    // closure_fnonce();  // Erro! Não pode ser chamada novamente
}

Closure com Estado Mutável

Uma das aplicações mais poderosas das closures é manter estado interno. Isso é especialmente útil para criar contadores, acumuladores e geradores:

// Closure que mantém estado mutável
fn contador() -> impl FnMut() -> i32 {
    let mut count = 0;
    move || {
        count += 1;
        count
    }
}

fn main() {
    let mut contar = contador();
    println!("{}", contar()); // 1
    println!("{}", contar()); // 2
    println!("{}", contar()); // 3
}

Note que FnMut é necessário aqui porque a closure modifica count a cada chamada. O tipo de retorno impl FnMut() -> i32 informa ao compilador que estamos retornando algo que implementa o trait FnMut.

Captura de Variáveis: As Diferenças Cruciais

Aqui está onde Rust brilha em comparação com Python. Enquanto Python usa referências e garbage collection, Rust exige que você seja explícito sobre como as variáveis são capturadas.

Python (com comportamento potencialmente problemático):

def criar_closures():
    closures = []
    for i in range(3):
        closures.append(lambda: print(f"Valor: {i}"))
    return closures

# Todas as closures imprimem "Valor: 2"!
for closure in criar_closures():
    closure()

Rust (comportamento correto por padrão):

fn criar_closures() -> Vec<Box<dyn Fn()>> {
    // Box<dyn Fn()> é necessário para armazenar closures de tamanhos distintos
    // em um Vec. 'dyn' indica despacho dinâmico (trait object).
    (0..3)
        .map(|i| Box::new(move || println!("Valor: {}", i)) as Box<dyn Fn()>)
        .collect()
}

fn main() {
    // Cada closure tem sua própria cópia de i
    for closure in criar_closures() {
        closure();  // Imprime 0, 1, 2
    }
}

Por que Box<dyn Fn()>? Cada closure em Rust tem um tipo único e anônimo — o compilador não consegue determinar o tamanho exato em tempo de compilação quando armazenamos closures diferentes em um mesmo Vec. Box<dyn Fn()> resolve isso alocando a closure no heap com tamanho fixo (um ponteiro). Quando você retorna uma única closure de uma função, prefira impl Fn() por ser mais eficiente.

Rust força você a pensar sobre ownership desde o início, prevenindo erros sutis que são comuns em Python!

Seção 2: Dominando Iteradores em Rust

Closures e iteradores caminham juntos em Rust — os adaptadores como map e filter recebem closures como argumento. Vamos explorar como os iteradores funcionam e como combiná-los com closures para criar pipelines poderosos.

`iter()`, `iter_mut()` e `into_iter()`: Quando Usar Cada Um

Antes de avançar, é essencial entender as três formas de iterar sobre uma coleção em Rust. Elas diferem fundamentalmente em como tratam o ownership:

Método	Tipo de acesso	O que acontece com a coleção
`.iter()`	`&T` — referência imutável	Coleção continua disponível
`.iter_mut()`	`&mut T` — referência mutável	Coleção continua disponível
`.into_iter()`	`T` — posse do valor	Coleção é consumida (movida)

fn main() {
    let mut numeros = vec![1, 2, 3];

    // iter(): empréstimo imutável — numeros ainda existe depois
    let soma: i32 = numeros.iter().sum();
    println!("Soma: {}", soma);

    // iter_mut(): empréstimo mutável — modifica os valores no lugar
    numeros.iter_mut().for_each(|n| *n *= 2);
    println!("Dobrados: {:?}", numeros); // [2, 4, 6]

    // into_iter(): adquire posse — numeros não pode mais ser usado
    let resultado: Vec<_> = numeros.into_iter().filter(|&n| n > 2).collect();
    println!("Filtrados: {:?}", resultado); // [4, 6]
    // println!("{:?}", numeros); // ERRO: numeros foi movido para o iterador
}

FromIterator e IntoIterator: A Magia Por Trás dos Iteradores

Em Rust, iteradores são preguiçosos por padrão — eles não fazem nada até que você os consuma. Isso é diferente do Python, onde muitas operações são imediatas (executadas no momento da chamada).

Os dois traits mais importantes são:

IntoIterator: Converte algo em um iterador
FromIterator: Constrói uma coleção a partir de um iterador

fn main() {
    let numeros = vec![1, 2, 3, 4, 5];

    // IntoIterator: converte Vec em iterador (move a posse de 'numeros')
    let iterador = numeros.into_iter();
    // Aqui, 'numeros' foi movido — não pode mais ser acessado

    // FromIterator: .collect() usa FromIterator para construir a nova coleção
    let novos_numeros: Vec<_> = iterador.collect();
    println!("{:?}", novos_numeros); // [1, 2, 3, 4, 5]
}

As Poderosas Adaptações: map, filter, collect

Aqui está onde a programação funcional realmente brilha em Rust! Vamos comparar com Python:

Python (avaliação imediata):

# Python: operações são aplicadas imediatamente
numeros = [1, 2, 3, 4, 5]
resultado = [x * 2 for x in numeros if x % 2 == 0]
print(resultado)  # [4, 8]

Rust (avaliação preguiçosa):

fn main() {
    let numeros = vec![1, 2, 3, 4, 5];

    // Rust: operações são preguiçosas, só executam quando consumidas
    let resultado: Vec<_> = numeros
        .into_iter()
        .filter(|x| x % 2 == 0)
        .map(|x| x * 2)
        .collect();

    println!("{:?}", resultado);  // [4, 8]
}

A beleza da abordagem Rust é que o compilador pode otimizar toda a cadeia de operações sem alocações intermediárias desnecessárias!

Adaptadores Avançados: chain, step_by e take

Além de map e filter, Rust oferece uma rica biblioteca de adaptadores que permitem construir pipelines sofisticados:

fn main() {
    // chain: concatena dois iteradores
    // step_by: pula N elementos entre cada item
    // take: limita o total de elementos retornados
    let resultado = (1..100)
        .chain(200..300)
        .step_by(2)
        .take(10)
        .collect::<Vec<_>>();

    println!("{:?}", resultado); // [1, 3, 5, 7, 9, 11, 13, 15, 17, 19]

    // Combinando closures com iteradores: flat_map, zip, fold
    let palavras = vec!["olá mundo", "rust é incrível"];
    let letras_unicas: std::collections::HashSet<char> = palavras
        .iter()
        .flat_map(|s| s.chars())
        .filter(|c| c.is_alphabetic())
        .collect();

    println!("Total de letras únicas: {}", letras_unicas.len());
}

Exemplo Prático: Processando Dados de Sensor

Vamos criar um exemplo mais complexo e realista que combina closures e iteradores em um pipeline completo:

struct LeituraSensor {
    valor: f64,
    timestamp: i64,
    valida: bool,
}

fn processar_leitura(leituras: Vec<LeituraSensor>) -> Vec<(i64, f64)> {
    leituras
        .into_iter()
        .filter(|leitura| leitura.valida)           // Filtra leituras válidas
        .filter(|leitura| leitura.valor >= 0.0)     // Valores não-negativos
        .map(|leitura| (leitura.timestamp, leitura.valor * 1.5))  // Transforma
        .filter(|(_, valor)| *valor <= 100.0)       // Remove valores excessivos
        .collect()                                   // Coleta em Vec
}

fn main() {
    let leituras = vec![
        LeituraSensor { valor: 25.5, timestamp: 1000, valida: true },
        LeituraSensor { valor: -5.0, timestamp: 1001, valida: true },
        LeituraSensor { valor: 75.0, timestamp: 1002, valida: false },
        LeituraSensor { valor: 150.0, timestamp: 1003, valida: true },
    ];

    let resultado = processar_leitura(leituras);
    println!("{:?}", resultado);  // [(1000, 38.25)]
}

Este exemplo mostra como Rust permite criar pipelines de processamento de dados claros, seguros e eficientes!

Seção 3: Avaliação Preguiçosa vs Avaliação Imediata

A Filosofia de Cada Linguagem

Python (Imediata):

Operações são executadas no momento da chamada
Mais fácil de depurar (você vê resultados intermediários)
Pode consumir mais memória (cria listas intermediárias)

Rust (Preguiçosa):

Operações só acontecem quando os resultados são realmente necessários
Permite otimizações poderosas (fusão de iteradores, eliminação de alocações)
Mais eficiente em termos de memória e desempenho

Exemplo de Performance

Vamos comparar o processamento de grandes conjuntos de dados:

Python (com list comprehensions):

# Python: cria listas intermediárias na memória
import time

dados = list(range(1_000_000))

inicio = time.time()
resultado = [x * 2 for x in dados if x % 3 == 0]
fim = time.time()
print(f"Tempo: {(fim - inicio):.4f}s")
print(f"Tamanho do resultado: {len(resultado)}")

Rust (com iteradores preguiçosos):

// Rust: não cria coleções intermediárias
use std::time::Instant;

fn main() {
    let dados: Vec<_> = (1..1_000_000).collect();

    let inicio = Instant::now();
    let resultado: Vec<_> = dados
        .into_iter()
        .filter(|x| x % 3 == 0)
        .map(|x| x * 2)
        .collect();
    let duracao = inicio.elapsed();

    println!("Tempo: {:.4?}s", duracao);
    println!("Tamanho do resultado: {}", resultado.len());
}

Em benchmarks, a versão Rust geralmente é 2-3x mais rápida e consome significativamente menos memória!

Zero-Cost Abstractions e Loop Fusion

Um dos pontos mais impressionantes do sistema de iteradores em Rust é que toda essa expressividade não tem custo em tempo de execução:

Loop Fusion: O compilador une automaticamente múltiplos filter e map em um único loop, sem iterações intermediárias
Inlining automático: Closures passadas para iteradores geralmente são embutidas diretamente no código gerado
Sem alocações desnecessárias: Adaptadores como map, filter, chain não alocam memória — apenas descrevem a transformação

Isso é o que Rust chama de zero-cost abstractions: você escreve código de alto nível, mas o compilador gera código tão eficiente quanto um loop manual em C.

Comparação com Python: Quando Cada Abordagem Brilha

List Comprehensions vs Iteradores Rust

Python (list/dict/set comprehensions):

# Python é excelente para expressões concisas
quadrados_pares = [x**2 for x in range(10) if x % 2 == 0]
dicionario = {x: x**2 for x in range(5)}
conjunto = {x for x in "abracadabra" if x not in "abc"}

Rust (iteradores):

// Rust é mais explícito mas igualmente poderoso
let quadrados_pares: Vec<_> = (0..10)
    .filter(|x| x % 2 == 0)
    .map(|x| x.pow(2))
    .collect();

let dicionario: std::collections::HashMap<_, _> = (0..5)
    .map(|x| (x, x.pow(2)))
    .collect();

let conjunto: std::collections::HashSet<_> = "abracadabra"
    .chars()
    .filter(|c| !"abc".contains(*c))
    .collect();

Generators Python vs Iteradores Rust

Python (generators):

# Generator expression (avaliação preguiçosa)
quadrados = (x**2 for x in range(1000000))
soma = sum(quadrados)  # Consome o generator

Rust (iteradores):

// Iteradores Rust são sempre preguiçosos
let quadrados = (0..1_000_000u64).map(|x| x.pow(2));
let soma: u64 = quadrados.sum();  // Consome o iterador

Erros Comuns de Pythonistas em Rust

Esquecer o collect():

// ERRO: Iteradores são preguiçosos — isso não processa nada!
let resultado = vec![1, 2, 3].iter().map(|x| x * 2);
// CORRETO:
let resultado: Vec<_> = vec![1, 2, 3].iter().map(|x| x * 2).collect();

Problemas de ownership em closures:

// ERRO: Tentar usar variável após mover para closure
let dados = vec![1, 2, 3];
let closure = move || println!("{:?}", dados);
println!("{:?}", dados);  // Erro! dados foi movido para a closure

Confusão entre iter(), into_iter(), iter_mut():

let mut numeros = vec![1, 2, 3];

// iter(): empréstimo imutável — coleção continua disponível
for n in numeros.iter() { /* lê &n */ }

// iter_mut(): empréstimo mutável — permite modificar os valores
for n in numeros.iter_mut() { *n *= 2; }

// into_iter(): adquire posse — consome o vetor
for n in numeros.into_iter() { /* n é dono do valor */ }
// numeros não existe mais aqui!

Conclusão: Por Que Rust Vale a Pena para Programação Funcional

Rust oferece o melhor dos dois mundos: a expressividade da programação funcional combinada com o desempenho e segurança de sistemas.

Use Rust quando:

Você precisa de máximo desempenho e eficiência de memória
A segurança contra erros é crítica (sistemas concorrentes, código de longa duração)
Você está trabalhando com grandes volumes de dados

Use Python quando:

A velocidade de desenvolvimento é prioridade
Você está prototipando ou explorando dados
O código não é performance-critical

O Que Aprendemos

Closures Rust são mais poderosas e seguras que as do Python, com sistema explícito de ownership
Traits Fn, FnMut, FnOnce definem como closures capturam e interagem com variáveis
impl Trait é preferível a Box<dyn Trait> quando possível (sem alocação de heap)
Iteradores Rust são preguiçosos por padrão, permitindo otimizações via loop fusion e zero-cost abstractions
iter(), iter_mut(), into_iter() servem propósitos distintos — escolha com atenção ao ownership
Avaliação preguiçosa em Rust é mais eficiente que a avaliação imediata do Python
Erros comuns de Pythonistas podem ser evitados entendendo ownership

Iteradores e closures são apenas parte do que torna Rust especial. Se você quer dominar completamente a linguagem e desbloquear todo seu potencial, o livro "Desbravando Rust" tem muito mais a oferecer!

📚 Adquira já seu exemplar de "Desbravando Rust" para se tornar um expert!

Nos próximos artigos, continuaremos explorando recursos avançados de Rust. Até lá, continue praticando e compartilhando suas descobertas! 🦀

[pt-BR] Concorrência e Paralelismo em Rust: Desvendando Threads e Async/Await para Pythonistas

Jose Luis da Cruz Junior — Tue, 15 Sep 2026 11:00:00 +0000

Por @zejuniortdr em Abr 01, 2026

Desenvolvedores Python que estão migrando para Rust frequentemente encontram desafios interessantes quando o assunto é concorrência e paralelismo. Enquanto Python tem seu próprio conjunto de ferramentas (threads, multiprocessing, asyncio), Rust oferece uma abordagem única que combina segurança de memória com alto desempenho.

Neste artigo, vamos explorar como Rust aborda essas questões fundamentais da programação moderna, sempre comparando com os conceitos que você já conhece do Python.

🧵 Introdução: O Desafio da Programação Concorrente

A programação concorrente é como coordenar vários cozinheiros em uma mesma cozinha:

Python: Os cozinheiros precisam revezar o uso das facas (GIL)
Rust: Cada cozinheiro tem suas próprias facas (ownership system)

A grande diferença é que Rust garante em tempo de compilação que não haverá conflitos, enquanto Python precisa confiar no desenvolvedor para evitar race conditions.

# Python: Race condition comum
counter = 0

def increment():
    global counter
    for _ in range(100000):
        counter += 1

import threading
threads = [threading.Thread(target=increment) for _ in range(10)]

for t in threads:
    t.start()
for t in threads:
    t.join()

print(counter)  # Resultado imprevisível - não será 1.000.000!

Rust previne esse problema em tempo de compilação:

// Rust: Tentativa ingênua que não compila
let mut counter = 0;

let handle = std::thread::spawn(|| {
    // ERRO: `closure may outlive the current function, but it borrows
    // `counter`, which is owned by the current function`
    for _ in 0..100000 {
        counter += 1;
    }
});

handle.join().unwrap();
println!("{}", counter);

O compilador Rust nos impede de cometer erros comuns de concorrência! 🛡️

🔒 Seção 1: Threads em Rust - Safety Garantido pelo Sistema de Tipos

Threads Seguras por Padrão

Enquanto em Python threads podem compartilhar estado livremente (com riscos), Rust exige que você pense cuidadosamente sobre o compartilhamento de dados.

# Python: Compartilhamento "fácil" mas perigoso
import threading

shared_data = {"counter": 0}

def worker():
    for _ in range(1000):
        shared_data["counter"] += 1

threads = []
for _ in range(10):
    t = threading.Thread(target=worker)
    threads.append(t)
    t.start()

for t in threads:
    t.join()

print(shared_data["counter"])  # Resultado inconsistente

Para compartilhar dados entre threads com segurança em Rust, precisamos de dois conceitos:

Mutex<T> (MUTual EXclusion): funciona como o threading.Lock() do Python. O Mutex garante que apenas um owner por vez possa acessar e modificar o dado interno.
Arc<T> (Atomic Reference Counter): é como um Rc (contador de referências) seguro para threads — ele permite que múltiplos owners compartilhem a posse do mesmo valor. Não tem equivalente direto simples em Python, pois o GIL faz isso implicitamente.

Juntos, Arc<Mutex<T>> é o padrão clássico para compartilhar estado mutável entre threads de forma segura: o Arc compartilha a propriedade e o Mutex protege o acesso ao dado interno.

// Rust: Compartilhamento seguro com Arc<Mutex<T>>
use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..10 {
        let counter = Arc::clone(&counter);
        // O `move` força o closure a *tomar posse* (ownership) da variável `counter`
        // (que é uma `Arc<Mutex<...>>`, já clonada para esta iteração).
        // Isso é necessário porque as threads podem durar mais que a função atual —
        // o sistema de ownership garante que os dados clonados vivam enquanto a thread precisar deles.
        let handle = thread::spawn(move || {
            for _ in 0..1000 {
                let mut num = counter.lock().unwrap();
                *num += 1;
            }
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }

    println!("Resultado: {}", *counter.lock().unwrap()); // Sempre 10000
}

O Sistema de Ownership como Guardião

O segredo da segurança das threads em Rust está no sistema de tipos:

Send: Permite que a propriedade de dados seja movida entre threads.
Sync: Permite que dados sejam acessados por múltiplas threads simultaneamente através de referências imutáveis (&T). Um tipo T é Sync se &T é Send.

Isso contrasta diretamente com o GIL do Python: enquanto o GIL protege tudo de forma global (limitando o paralelismo), os traits Send/Sync permitem proteção granular — você usa Mutex apenas nos dados que realmente precisam de exclusão mútua, o que é mais eficiente e explícito.

Esses traits são automaticamente implementados quando é seguro fazê-lo, e o compilador valida isso para você.

⚡ Seção 2: Async/Await em Rust - Performance sem Bloqueio

O Paradigma Assíncrono

A assincronia em Rust é diferente do Python: não há GIL e as tarefas podem executar verdadeiramente em paralelo quando há múltiplos núcleos disponíveis.

# Python: asyncio com GIL
import asyncio

async def tarefa_lenta(nome, segundos):
    print(f"{nome} iniciou")
    await asyncio.sleep(segundos)
    print(f"{nome} terminou")

async def main():
    await asyncio.gather(
        tarefa_lenta("Tarefa 1", 2),
        tarefa_lenta("Tarefa 2", 1),
        tarefa_lenta("Tarefa 3", 3)
    )

asyncio.run(main())

Em Rust, async/await é mais sobre concorrência do que paralelismo — isso significa que uma única thread pode gerenciar milhares de operações de I/O concorrentes (como esperar respostas de rede) de forma eficiente, alternando entre elas. O paralelismo real (múltiplos núcleos trabalhando ao mesmo tempo) ainda é alcançado pelo runtime async (como o Tokio) ao distribuir essas tarefas por uma pool de threads de trabalho.

// Rust: async/await com tokio
use tokio::time::{sleep, Duration};

async fn tarefa_lenta(nome: &str, segundos: u64) {
    println!("{} iniciou", nome);
    sleep(Duration::from_secs(segundos)).await;
    println!("{} terminou", nome);
}

#[tokio::main]
async fn main() {
    let tarefa1 = tarefa_lenta("Tarefa 1", 2);
    let tarefa2 = tarefa_lenta("Tarefa 2", 1);
    let tarefa3 = tarefa_lenta("Tarefa 3", 3);

    // `tokio::join!` aguarda todas as tarefas completarem (sem dependências extras)
    tokio::join!(tarefa1, tarefa2, tarefa3);
}

Runtime vs Biblioteca

Uma diferença fundamental: Python tem um runtime built-in para async (asyncio), enquanto Rust usa bibliotecas externas (tokio, async-std):

Python: asyncio é parte da biblioteca padrão — solução oficial e única
Rust: Você escolhe seu runtime conforme a necessidade

Esta abordagem dá mais flexibilidade ao programador Rust. Você pode escolher tokio para alta performance e um ecossistema rico de bibliotecas async, ou async-std para uma API mais próxima da stdlib. Em contraste, Python oferece o asyncio como solução única na biblioteca padrão.

🐍 Seção 3: Comparação com Python - GIL, Threads e Asyncio

A Maldição do GIL (Global Interpreter Lock)

O GIL do Python é provavelmente o maior contraste com Rust:

Python: Apenas uma thread executa código Python por vez (com exceções)
Rust: Threads podem executar verdadeiramente em paralelo

# Python: CPU-bound com threads (não escala)
import threading
import time

def trabalho_pesado():
    n = 0
    for i in range(10000000):
        n += i
    return n

# Threads para trabalho CPU-bound não escalam por causa do GIL
inicio = time.time()
threads = []
for _ in range(4):
    t = threading.Thread(target=trabalho_pesado)
    threads.append(t)
    t.start()

for t in threads:
    t.join()

print(f"Threads Python: {time.time() - inicio:.2f}s")

Para trabalho CPU-bound em Python, você precisaria usar multiprocessing:

# Python: CPU-bound com multiprocessing
from multiprocessing import Pool
import time

def trabalho_pesado(_):
    n = 0
    for i in range(10000000):
        n += i
    return n

inicio = time.time()
with Pool(4) as p:
    p.map(trabalho_pesado, range(4))
print(f"Multiprocessing Python: {time.time() - inicio:.2f}s")

Em Rust, threads escalam perfeitamente para trabalho CPU-bound:

// Rust: CPU-bound com threads (escala linearmente)
use std::thread;
use std::time::Instant;

fn trabalho_pesado() -> i64 {
    let mut n = 0;
    for i in 0..10000000 {
        n += i as i64;
    }
    n
}

fn main() {
    let inicio = Instant::now();

    let mut handles = vec![];
    for _ in 0..4 {
        handles.push(thread::spawn(|| {
            trabalho_pesado();
        }));
    }

    for handle in handles {
        handle.join().unwrap();
    }

    println!("Threads Rust: {:.2?}", inicio.elapsed());
}

IO-bound: Async vs Threads

Para operações de I/O (arquivos, rede, banco de dados), ambas as linguagens têm boas soluções:

# Python: I/O-bound com asyncio (eficiente)
import aiohttp
import asyncio

async def fetch(url):
    async with aiohttp.ClientSession() as session:
        async with session.get(url) as response:
            return await response.text()

async def main():
    urls = ["http://httpbin.org/get"] * 10
    tasks = [fetch(url) for url in urls]
    # asyncio.gather aceita uma lista dinâmica de tarefas com sintaxe concisa
    responses = await asyncio.gather(*tasks)
    return len(responses)

// Rust: I/O-bound com async (eficiente)
// Cargo.toml: reqwest = { version = "0.12", features = ["json"] }
use reqwest;
use tokio::task::JoinSet;

async fn fetch(url: &str) -> Result<String, reqwest::Error> {
    reqwest::get(url).await?.text().await
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let urls = vec!["http://httpbin.org/get"; 10];

    // JoinSet gerencia um conjunto dinâmico de tarefas — sem dependências extras
    let mut set = JoinSet::new();
    for url in urls {
        set.spawn(async move { fetch(url).await });
    }

    let mut count = 0;
    while let Some(result) = set.join_next().await {
        result??;
        count += 1;
    }
    // Nota: Python's asyncio.gather(*tasks) é mais conciso para listas dinâmicas.
    // Em Rust, JoinSet (tokio) ou futures::future::join_all (crate `futures`) são as alternativas,
    // contrabalançadas pela performance e pelo controle fino que Rust oferece.
    println!("Total de respostas: {}", count);
    Ok(())
}

🚀 Seção 4: Exemplo Prático - Servidor Web Concorrente

Vamos implementar um servidor HTTP simples que pode lidar com múltiplas requisições concorrentemente.

Versão Python com Flask + Threading

# Python: Servidor simples com Flask
from flask import Flask
import time
import threading

app = Flask(__name__)

@app.route('/lenta/<int:segundos>')
def rota_lenta(segundos):
    time.sleep(segundos)  # Simula trabalho bloqueante
    return f"Dormi {segundos}s no thread {threading.get_ident()}"

if __name__ == '__main__':
    # Flask usa threads por padrão para lidar com concorrência
    app.run(threaded=True, port=8000)

Este servidor pode lidar com múltiplas requisições usando threads, mas cada thread consome recursos significativos do sistema.

Versão Rust com Actix Web (Async)

// Rust: Servidor async com Actix Web
use actix_web::{get, web, App, HttpServer, HttpResponse};
use std::time::Duration;
use tokio::time::sleep;

#[get("/lenta/{segundos}")]
async fn rota_lenta(segundos: web::Path<u64>) -> HttpResponse {
    sleep(Duration::from_secs(*segundos)).await; // Não bloqueia o thread
    HttpResponse::Ok().body(format!("Dormi {}s", segundos))
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new().service(rota_lenta)
    })
    .bind("127.0.0.1:8080")?
    .workers(4)  // Número de threads de trabalho
    .run()
    .await
}

A versão Rust é muito mais eficiente em termos de recursos porque:

Usa um número fixo de threads (workers)
As tarefas async não bloqueiam os threads
Pode lidar com milhares de conexões concorrentes com poucos threads

Teste de Carga Simples

# Python: Teste de carga para os servidores
import requests
import time
from concurrent.futures import ThreadPoolExecutor  # necessário para ThreadPoolExecutor

def testar_servidor(porta, url, num_requisicoes):
    inicio = time.time()

    # O parâmetro `_` recebe cada número do range mas é ignorado —
    # o importante é disparar `num_requisicoes` chamadas concorrentes.
    def fazer_requisicao(_):
        return requests.get(f"http://localhost:{porta}{url}").status_code

    with ThreadPoolExecutor(max_workers=100) as executor:
        # Executa a função 'fazer_requisicao' para cada elemento no range
        resultados = list(executor.map(fazer_requisicao, range(num_requisicoes)))

    tempo_total = time.time() - inicio
    print(f"Porta {porta}: {num_requisicoes} reqs em {tempo_total:.2f}s")

# Testar ambos
testar_servidor(8000, "/lenta/1", 100)  # Flask com threads
testar_servidor(8080, "/lenta/1", 100)  # Actix com async

🤔 Quando Usar Threads vs Async/Await em Rust

Threads São Ideais Para:

Trabalho CPU-bound que pode ser paralelizado
Operações bloqueantes que não têm suporte async
Código simples onde o overhead do async não se justifica

Async/Await É Ideal Para:

Operações I/O-bound (rede, arquivos, banco de dados)
Servidores que precisam lidar com muitas conexões
Operações não-bloqueantes onde a eficiência é crítica

Paralelismo de Dados com `rayon`

Para trabalho CPU-bound que envolve processar coleções e iteradores, a crate rayon é uma ferramenta fantástica e muito popular. Ela oferece paralelismo quase automático — basta trocar .iter() por .par_iter():

// Cargo.toml: rayon = "1"
use rayon::prelude::*;

fn main() {
    let data = vec!;[1][2]

    // Processa cada elemento em paralelo entre todos os núcleos disponíveis!
    let resultados: Vec<_> = data.par_iter().map(|x| x * x).collect();
    println!("{:?}", resultados); //[1]
}

Para Pythonistas, isso é comparável a usar multiprocessing.Pool com map, mas com uma API muito mais ergonômica e sem o overhead de processos separados.

Comparação de Performance

Cenário	Python (Threads)	Python (Async)	Rust (Threads)	Rust (Async)
CPU-bound	⚠️ Com multiprocessing	❌ Não aplicável	⭐⭐ Excelente	❌ Não aplicável
I/O-bound (1000 conexões)	⚠️ Consome muitos recursos	⭐ Bom	⭐⭐ Excelente	⭐⭐⭐ Excelente+
Simplicidade	⭐⭐ Fácil	⚠️ Complexo	⭐⭐ Moderado	⚠️ Complexo

⚠️ Erros Comuns de Pythonistas em Rust

1. Tentar Usar Threads para Tudo Como no Python

// ❌ Errado: Criar threads demais como faria em Python
for _ in 0..1000 {
    thread::spawn(|| { /* ... */ }); // Consome muitos recursos
}

// ✅ Correto: Usar async para I/O ou thread pool para CPU
let pool = ThreadPool::new(4); // Pool com número fixo de threads
for _ in 0..1000 {
    pool.execute(|| { /* ... */ });
}

2. Esquecer de `.await` em Funções Async

// ❌ Errado: Esquecer o .await
async fn processar_dados() {
    buscar_dados(); // Esqueceu .await - não executa!
}

// ✅ Correto: Usar .await
async fn processar_dados() {
    buscar_dados().await; // Executa corretamente
}

3. Bloquear Threads de Execução com Operações CPU-intensivas

// ❌ Errado: Trabalho CPU-intensive em contexto async
async fn rota_lenta() {
    trabalho_pesado_cpu(); // Bloqueia o executor!
}

// ✅ Correto: Mover trabalho CPU-intensive para thread dedicado
async fn rota_lenta() {
    let resultado = tokio::task::spawn_blocking(|| {
        trabalho_pesado_cpu() // Executa em thread separado
    }).await.unwrap();
    // ... resto async
}

🎯 Conclusão: Por Que Rust Brilha em Concorrência

Rust oferece o melhor dos dois mundos: a segurança de memória que previne erros concorrentes comuns e o desempenho que permite tirar máximo proveito do hardware moderno.

Para Pythonistas, aprender Rust significa:

Entender como a concorrência pode ser segura por padrão
Aprender a pensar em termos de ownership e borrowing
Descobrir que async/await pode ser mais eficiente que threads tradicionais
Ganhar habilidades para escrever sistemas concorrentes mais robustos

Em termos filosóficos, as duas linguagens representam trade-offs conscientes: Rust exige mais upfront — tipos explícitos, gerenciamento de ownership e um compilador rigoroso — para garantir segurança máxima e performance previsível. Python oferece mais facilidade inicial com tipagem dinâmica e o GIL como rede de segurança, mas esses atalhos têm um custo em performance e em race conditions que só aparecem em produção. Conhecer Rust muda a forma como você programa em qualquer linguagem.

📚 O Que Aprendemos

Threads em Rust são seguras graças ao sistema de tipos e traits Send/Sync
Async/Await em Rust é implementado através de bibliotecas como tokio e oferece alta eficiência para I/O
O GIL do Python limita a verdadeira paralelização com threads, enquanto Rust escala linearmente
Threads são ideais para trabalho CPU-bound, enquanto async é melhor para I/O-bound
rayon é a ferramenta certa para paralelismo de dados em coleções com mínima mudança de código
Erros comuns incluem criar threads demais, esquecer await calls e bloquear o executor com código CPU-intensivo

A jornada de aprendizado de concorrência em Rust é recompensadora e transformará como você pensa sobre programação paralela, mesmo quando voltar ao Python.

Quer se aprofundar ainda mais? Confira o livro completo "Desbravando Rust" em desbravandorust.com.br para dominar todos esses conceitos com exemplos práticos e exercícios!

[pt-BR] Desmistificando Traits em Rust: Herança para Pythonistas

Jose Luis da Cruz Junior — Tue, 08 Sep 2026 11:00:00 +0000

Por @zejuniortdr em Mar 28, 2026

👋 Bem-vindos, desbravadores! Se você vem do Python e está começando sua jornada em Rust, provavelmente já se deparou com o conceito de traits. Talvez você tenha pensado: "Isso parece com herança de classes do Python, mas não exatamente..."

Neste post, vamos explorar como traits em Rust oferecem uma alternativa poderosa e flexível à herança tradicional de classes que você conhece do Python. Vamos desmistificar esse conceito fundamental com muitas comparações e exemplos práticos!

Introdução: Herança vs Composição

No mundo orientado a objetos do Python, a herança é o mecanismo principal para reutilização de código. Você cria uma classe base com comportamentos e propriedades comuns, e depois cria classes derivadas que herdam essas características:

# Exemplo de herança em Python
class Animal:
    def fazer_som(self):
        raise NotImplementedError("Método abstrato")

    def mover(self):
        print("Movendo-se...")

class Cachorro(Animal):
    def fazer_som(self):
        return "Au au!"

class Gato(Animal):
    def fazer_som(self):
        return "Miau!"

Em Rust, a abordagem é diferente. Em vez de herança, Rust utiliza composição através de traits para compartilhar comportamento entre tipos. Traits definem um contrato de comportamento que tipos podem implementar, sem herdar propriedades ou estado.

Rust prioriza composição sobre herança - um princípio de design que também é recomendado em Python, mas que Rust torna explícito na linguagem.

🧩 O que são Traits e como funcionam

Traits em Rust são similares a interfaces em outras linguagens de programação, mas com superpoderes! Uma trait define um conjunto de métodos que um tipo deve implementar.

Pense nas traits como contratos de comportamento. Elas dizem: "Se você quiser ser considerado um X, você precisa ser capaz de fazer Y".

Sintaxe básica de Traits

Vamos começar com um exemplo simples:

// Definindo uma trait
trait FazSom {
    fn fazer_som(&self) -> String;
}

// Implementando a trait para um tipo específico
struct Cachorro {
    nome: String,
}

impl FazSom for Cachorro {
    fn fazer_som(&self) -> String {
        format!("{} faz: Au au!", self.nome)
    }
}

// Outra implementação
struct Gato {
    nome: String,
}

impl FazSom for Gato {
    fn fazer_som(&self) -> String {
        format!("{} faz: Miau!", self.nome)
    }
}

No Python, isso seria semelhante a uma classe abstrata com métodos abstratos, mas com uma diferença crucial: em Rust, você pode implementar traits para tipos que você não definiu (desde que a trait ou o tipo estejam no seu crate).

Traits com implementações padrão

Uma das características mais poderosas das traits são as implementações padrão:

trait FazSom {
    fn fazer_som(&self) -> String;

    // Método com implementação padrão
    fn apresentar(&self) -> String {
        format!("Eu sou um animal que faz: {}", self.fazer_som())
    }
}

// Agora só precisamos implementar fazer_som()
impl FazSom for Cachorro {
    fn fazer_som(&self) -> String {
        "Au au!".to_string()
    }
}

// Podemos sobrescrever o padrão se quisermos
impl FazSom for Gato {
    fn fazer_som(&self) -> String {
        "Miau!".to_string()
    }

    fn apresentar(&self) -> String {
        format!("Sou um gato elegante que diz: {}", self.fazer_som())
    }
}

Isso é semelhante aos métodos com implementação padrão em classes base abstratas do Python, mas com muito mais flexibilidade.

🔧 Implementando Traits para tipos customizados

Agora vamos ver um exemplo mais prático e completo. Vamos criar um sistema simples de formas geométricas com traits:

# Exemplo em Python com herança
class Forma:
    def area(self):
        raise NotImplementedError

    def perimetro(self):
        raise NotImplementedError

class Retangulo(Forma):
    def __init__(self, largura, altura):
        self.largura = largura
        self.altura = altura

    def area(self):
        return self.largura * self.altura

    def perimetro(self):
        return 2 * (self.largura + self.altura)

class Circulo(Forma):
    def __init__(self, raio):
        self.raio = raio

    def area(self):
        return 3.14159 * self.raio ** 2

    def perimetro(self):
        return 2 * 3.14159 * self.raio

Agora veja como ficaria em Rust com traits:

// Definindo a trait FormaGeometrica
trait FormaGeometrica {
    fn area(&self) -> f64;
    fn perimetro(&self) -> f64;

    // Método com implementação padrão que usa os outros métodos da trait
    fn descricao(&self) -> String {
        format!("Área: {:.2}, Perímetro: {:.2}", self.area(), self.perimetro())
    }
}

// Definindo structs para nossas formas
struct Retangulo {
    largura: f64,
    altura: f64,
}

// Implementando a trait para Retangulo
impl FormaGeometrica for Retangulo {
    fn area(&self) -> f64 {
        self.largura * self.altura
    }

    fn perimetro(&self) -> f64 {
        2.0 * (self.largura + self.altura)
    }
}

struct Circulo {
    raio: f64,
}

impl FormaGeometrica for Circulo {
    fn area(&self) -> f64 {
        std::f64::consts::PI * self.raio.powi(2)
    }

    fn perimetro(&self) -> f64 {
        2.0 * std::f64::consts::PI * self.raio
    }

    // Sobrescrevendo o método padrão chamando outros métodos da trait
    fn descricao(&self) -> String {
        format!(
            "Círculo com raio {:.2}: Área: {:.2}, Perímetro: {:.2}",
            self.raio,
            self.area(),
            self.perimetro()
        )
    }
}

// Função genérica que aceita qualquer tipo que implemente FormaGeometrica
fn imprimir_info<T: FormaGeometrica>(forma: &T) {
    println!("{}", forma.descricao());
}

fn main() {
    let retangulo = Retangulo { largura: 5.0, altura: 3.0 };
    let circulo = Circulo { raio: 2.5 };

    imprimir_info(&retangulo);
    imprimir_info(&circulo);
}

A diferença fundamental aqui é que em Rust, a trait é um contrato separado da definição do tipo, enquanto em Python o comportamento é definido junto com o tipo através da herança.

⚠️ Importante: Ao sobrescrever um método padrão de uma trait, você deve usar os outros métodos da própria trait (self.area(), self.perimetro()). Não existe equivalente a super() do Python — não há hierarquia de herança de estado em Rust.

🎭 Trait Objects e Despacho Dinâmico

Uma das características mais interessantes das traits é a capacidade de criar trait objects para polimorfismo em tempo de execução.

Vamos ver primeiro como o polimorfismo funciona em Python:

# Polimorfismo em Python (dinâmico por natureza)
formas = [Retangulo(5, 3), Circulo(2.5)]

for forma in formas:
    print(f"Área: {forma.area()}")
    print(f"Perímetro: {forma.perimetro()}")

Em Rust, precisamos ser explícitos sobre quando queremos despacho dinâmico usando trait objects:

fn main() {
    // Declaramos as variáveis com seus tipos concretos primeiro
    let retangulo = Retangulo { largura: 5.0, altura: 3.0 };
    let circulo = Circulo { raio: 2.5 };

    // Criando um vetor de trait objects: cada elemento é uma referência
    // dinâmica a qualquer tipo que implemente FormaGeometrica
    let formas: Vec<&dyn FormaGeometrica> = vec![&retangulo, &circulo];

    for forma in formas {
        println!("{}", forma.descricao());
    }
}

O que é `dyn`?

A palavra-chave dyn indica despacho dinâmico (dynamic dispatch). Quando você usa &dyn MinhaTraint, o Rust não sabe em tempo de compilação qual tipo concreto está por trás da referência — ele descobre isso em tempo de execução usando uma vtable (tabela de ponteiros de funções), exatamente como Python faz com todos os seus objetos.

Sem dyn, o Rust precisaria conhecer o tipo exato em tempo de compilação (o que é o caso dos generics, como veremos a seguir).

As três formas de usar traits em Rust

É importante entender as diferenças entre as três formas principais de usar traits:

// 1. impl Trait para um tipo específico
impl FormaGeometrica for Retangulo { /* ... */ }

// 2. Trait bound em generics (despacho estático — mais rápido)
//    O compilador gera uma versão específica para cada tipo em compile-time
fn imprimir<T: FormaGeometrica>(forma: &T) {
    println!("{}", forma.descricao());
}

// 3. Trait object com dyn (despacho dinâmico — mais flexível)
//    O tipo concreto é resolvido em runtime via vtable
fn imprimir_dinamico(forma: &dyn FormaGeometrica) {
    println!("{}", forma.descricao());
}

Trait Objects vs Generics

Característica	Generics (`<T: Trait>`)	Trait Objects (`dyn Trait`)
Quando o tipo é resolvido	Compile-time	Runtime
Performance	Mais rápida (zero-cost)	Overhead de vtable
Coleções heterogêneas	❌ Não suporta	✅ Suporta
Tamanho em memória	Conhecido em compile-time	Requer ponteiro (`Box`, `&`)
Caso de uso ideal	Tipos conhecidos, performance crítica	Plugins, coleções polimórficas

// Generics: melhor performance — tipo resolvido em compile-time
fn processar_generico<T: FormaGeometrica>(forma: &T) {
    println!("{}", forma.descricao());
}

// Trait objects: mais flexível — permite coleções heterogêneas
fn processar_dinamico(forma: &dyn FormaGeometrica) {
    println!("{}", forma.descricao());
}

// Com Box<dyn Trait>, você pode armazenar valores owned de tipos diferentes
fn criar_formas() -> Vec<Box<dyn FormaGeometrica>> {
    vec![
        Box::new(Retangulo { largura: 5.0, altura: 3.0 }),
        Box::new(Circulo { raio: 2.5 }),
    ]
}

🔑 Tipos Associados em Traits

Traits podem declarar tipos associados (associated types), que permitem que cada implementação defina seus próprios tipos internos. Isso é muito usado em traits da biblioteca padrão como Iterator.

trait Repository {
    type Item; // tipo associado — cada implementação define o seu

    fn get(&self, id: i32) -> Option<Self::Item>;
    fn save(&mut self, item: Self::Item) -> Result<(), String>;
}

struct Usuario {
    id: i32,
    nome: String,
}

struct UsuarioRepository {
    usuarios: Vec<Usuario>,
}

impl Repository for UsuarioRepository {
    type Item = Usuario; // aqui definimos o tipo concreto

    fn get(&self, id: i32) -> Option<Self::Item> {
        self.usuarios.iter()
            .find(|u| u.id == id)
            .map(|u| Usuario { id: u.id, nome: u.nome.clone() })
    }

    fn save(&mut self, item: Self::Item) -> Result<(), String> {
        self.usuarios.push(item);
        Ok(())
    }
}

Em Python, você simularia isso com generics de tipo (Generic[T]) ou type hints. Em Rust, os tipos associados tornam a intenção explícita e são verificados pelo compilador.

⚙️ Métodos Associados (Funções Estáticas)

Traits também podem definir funções associadas — equivalente aos métodos de classe (@classmethod) ou métodos estáticos do Python. A diferença é que essas funções não recebem &self:

trait Fabrica {
    fn novo() -> Self; // sem &self — é uma função associada
}

struct Ponto {
    x: f64,
    y: f64,
}

impl Fabrica for Ponto {
    fn novo() -> Self {
        Ponto { x: 0.0, y: 0.0 }
    }
}

// Equivalente Python:
// class Ponto:
//     @classmethod
//     def novo(cls):
//         return cls(x=0.0, y=0.0)

fn main() {
    let p = Ponto::novo(); // chamada via nome do tipo, sem instância
}

🌐 Implementações Genéricas (Blanket Implementations)

Um recurso poderoso e exclusivo do Rust são as blanket implementations: implementar uma trait para todos os tipos que já implementam outra trait. Isso é amplamente usado na biblioteca padrão:

// Exemplo: implementar uma trait para todos os tipos que implementam FormaGeometrica
trait Exibivel {
    fn exibir(&self);
}

// Blanket impl: qualquer tipo que impl FormaGeometrica também ganha Exibivel
impl<T: FormaGeometrica> Exibivel for T {
    fn exibir(&self) {
        println!("Forma -> {}", self.descricao());
    }
}

// Agora Retangulo e Circulo ganham exibir() automaticamente!
fn main() {
    let r = Retangulo { largura: 4.0, altura: 2.0 };
    r.exibir(); // Forma -> Área: 8.00, Perímetro: 12.00
}

A biblioteca padrão usa blanket implementations extensivamente. Por exemplo, o trait ToString é implementado automaticamente para todo tipo que implementa Display:

// Na stdlib: impl<T: Display> ToString for T { ... }
// Por isso podemos chamar .to_string() em qualquer tipo com Display!

🔄 Comparação com Python: Herança vs Traits

Vamos analisar as diferenças fundamentais entre a abordagem do Python e do Rust:

Característica	Python (Herança)	Rust (Traits)
Reutilização de código	Através de herança de classes	Através de implementação de traits
Herança múltipla	Suportada (com complexidade)	Não existe, mas traits substituem
Composição	Possível, mas não forçada	Padrão da linguagem
Contratos explícitos	ABCs (Abstract Base Classes)	Traits
Despacho de métodos	Sempre dinâmico	Estático (generics) ou dinâmico (trait objects)
Extensibilidade	Pode modificar classes existentes	Pode implementar traits para tipos existentes

Herança múltipla vs Traits

Um dos problemas mais conhecidos da herança múltipla em Python é o problema do diamante:

# Problema do diamante em Python
class A:
    def metodo(self):
        print("A")

class B(A):
    def metodo(self):
        print("B")

class C(A):
    def metodo(self):
        print("C")

class D(B, C):
    pass

d = D()
d.metodo()  # Qual método é chamado? Depende da MRO!

Em Rust, traits resolvem esse problema elegantemente. Como não há herança de estado, cada trait é um contrato independente. Quando B e C são supertraits de A, o tipo D implementa explicitamente cada uma — sem ambiguidade:

trait A {
    fn metodo(&self);
}

trait B: A {} // B requer que A esteja implementada, mas não redefine metodo

trait C: A {} // idem para C

struct D;

impl A for D {
    fn metodo(&self) {
        println!("A implementado para D");
    }
}

impl B for D {} // compila porque A já está implementada para D
impl C for D {} // idem

fn main() {
    let d = D;
    d.metodo(); // sem ambiguidade: só existe uma implementação de metodo para D
}

Se B e C definirem métodos próprios com o mesmo nome, o Rust força o uso de sintaxe qualificada para desambiguar — tornando a intenção explícita, ao contrário do MRO implícito do Python:

trait B: A {
    fn comportamento(&self) { println!("Comportamento de B"); }
}

trait C: A {
    fn comportamento(&self) { println!("Comportamento de C"); }
}

struct D;
impl A for D { fn metodo(&self) { println!("A"); } }
impl B for D {}
impl C for D {}

fn main() {
    let d = D;
    B::comportamento(&d); // explícito: chama B::comportamento
    C::comportamento(&d); // explícito: chama C::comportamento
}

📚 Traits Importantes da Biblioteca Padrão

Rust possui um conjunto rico de traits na stdlib que você deve conhecer e implementar para seus tipos:

Trait	Finalidade	Equivalente Python
`Display` / `Debug`	Formatação de strings	`__str__` / `__repr__`
`Clone` / `Copy`	Clonar / copiar valores	`__copy__` / `copy.deepcopy`
`From` / `Into`	Conversões entre tipos	`__init__` com outro tipo
`Iterator`	Iteração com `next()`	`__iter__` / `__next__`
`Drop`	Cleanup ao sair de escopo	`__del__`
`PartialEq` / `Eq`	Comparação de igualdade	`__eq__`
`PartialOrd` / `Ord`	Comparação de ordem	`__lt__`, `__gt__`

use std::fmt;

struct Ponto {
    x: f64,
    y: f64,
}

// Display: como o tipo aparece para o usuário
impl fmt::Display for Ponto {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        write!(f, "({:.2}, {:.2})", self.x, self.y)
    }
}

// From: conversão idiomática entre tipos
impl From<(f64, f64)> for Ponto {
    fn from(tupla: (f64, f64)) -> Self {
        Ponto { x: tupla.0, y: tupla.1 }
    }
}

fn main() {
    let p = Ponto::from((3.0, 4.0));
    println!("{}", p); // (3.00, 4.00)

    // Into é gerado automaticamente quando From é implementado
    let p2: Ponto = (1.0, 2.0).into();
    println!("{}", p2); // (1.00, 2.00)
}

⚠️ Erros Comuns de Pythonistas em Rust

Vamos destacar alguns erros comuns que programadores Python cometem ao começar com traits em Rust:

Tentar imitar herança hierárquica: Em Rust, pense em composição, não em hierarquia de herança.
Usar dyn quando generics bastam: Prefira generics quando os tipos são conhecidos em compile-time — a performance é melhor (zero-cost abstraction).
Subutilizar enums: Muitas vezes, um enum é uma solução melhor que trait objects quando você sabe todos os tipos possíveis antecipadamente.

// Às vezes é melhor usar enum que trait objects
enum Forma {
    Retangulo(Retangulo),
    Circulo(Circulo),
}

impl FormaGeometrica for Forma {
    fn area(&self) -> f64 {
        match self {
            Forma::Retangulo(r) => r.area(),
            Forma::Circulo(c) => c.area(),
        }
    }

    fn perimetro(&self) -> f64 {
        match self {
            Forma::Retangulo(r) => r.perimetro(),
            Forma::Circulo(c) => c.perimetro(),
        }
    }
}

Esquecer o dyn: Quando usar trait objects, não esqueça da palavra-chave dyn:

// Errado (Rust moderno exige dyn):  Vec<&FormaGeometrica>
// Correto:                          Vec<&dyn FormaGeometrica>

Não usar traits padrão: Rust tem muitas traits úteis na biblioteca padrão (Debug, Clone, Copy, etc). Implemente-as para seus tipos!

🏗️ Exemplo Prático Completo: Sistema de Notificação

Vamos criar um sistema de notificação que pode enviar mensagens por diferentes canais (email, SMS, push):

# Versão Python com herança
class Notificador:
    def enviar(self, mensagem: str) -> bool:
        raise NotImplementedError

class NotificadorEmail(Notificador):
    def __init__(self, email: str):
        self.email = email

    def enviar(self, mensagem: str) -> bool:
        print(f"Enviando email para {self.email}: {mensagem}")
        return True

class NotificadorSMS(Notificador):
    def __init__(self, telefone: str):
        self.telefone = telefone

    def enviar(self, mensagem: str) -> bool:
        print(f"Enviando SMS para {self.telefone}: {mensagem}")
        return True

# Uso
notificadores = [NotificadorEmail("user@example.com"), NotificadorSMS("+551199999999")]

for notificador in notificadores:
    notificador.enviar("Olá!")

Agora a versão Rust:

// Versão Rust com traits
trait Notificador {
    fn enviar(&self, mensagem: &str) -> bool;
}

struct NotificadorEmail {
    email: String,
}

impl Notificador for NotificadorEmail {
    fn enviar(&self, mensagem: &str) -> bool {
        println!("Enviando email para {}: {}", self.email, mensagem);
        true
    }
}

struct NotificadorSMS {
    telefone: String,
}

impl Notificador for NotificadorSMS {
    fn enviar(&self, mensagem: &str) -> bool {
        println!("Enviando SMS para {}: {}", self.telefone, mensagem);
        true
    }
}

struct NotificadorPush {
    device_id: String,
}

impl Notificador for NotificadorPush {
    fn enviar(&self, mensagem: &str) -> bool {
        println!("Enviando notificação push para {}: {}", self.device_id, mensagem);
        true
    }
}

fn main() {
    // Box<dyn Trait> permite armazenar tipos owned diferentes no mesmo vetor
    let notificadores: Vec<Box<dyn Notificador>> = vec![
        Box::new(NotificadorEmail { email: "user@example.com".to_string() }),
        Box::new(NotificadorSMS { telefone: "+551199999999".to_string() }),
        Box::new(NotificadorPush { device_id: "device123".to_string() }),
    ];

    for notificador in notificadores {
        notificador.enviar("Olá!");
    }
}

📚 O que aprendemos

Neste post exploramos as traits em Rust e como elas oferecem uma alternativa poderosa à herança tradicional do Python:

🧩 Traits são contratos de comportamento: Elas definem o que um tipo pode fazer, não o que ele é
🔧 Implementação flexível: Podemos implementar traits para tipos existentes, inclusive tipos da biblioteca padrão
🎭 dyn e despacho dinâmico: dyn Trait sinaliza que o tipo é resolvido em runtime via vtable — use quando precisar de coleções heterogêneas
⚡ Generics vs trait objects: Generics são mais rápidos (zero-cost, compile-time); trait objects são mais flexíveis (runtime)
🔑 Tipos associados: Permitem que cada implementação defina seus próprios tipos internos
⚙️ Funções associadas: Traits podem ter métodos sem &self, equivalentes a @classmethod do Python
🌐 Blanket implementations: Implementar uma trait para todos os tipos que satisfazem outra condição
🔄 Composição sobre herança: Rust incentiva compor comportamentos em vez de criar hierarquias de herança
📚 Traits da stdlib: Display, From/Into, Iterator, Drop e outras devem ser implementadas para seus tipos
⚠️ Armadilhas comuns: Evite imitar padrões de herança e aprenda a pensar em composição

Traits são um dos conceitos mais poderosos do Rust, oferecendo flexibilidade e segurança ao mesmo tempo. Elas representam uma maneira moderna de pensar sobre polimorfismo e reutilização de código, diferente mas complementar à herança tradicional do Python.

💡 Quer se aprofundar ainda mais em Rust?

Adquira o livro 'Desbravando Rust' para uma jornada completa desde os fundamentos até tópicos avançados!

📖 Disponível em: desbravandorust.com.br

Nos próximos posts, continuaremos explorando conceitos avançados de Rust. Deixe nos comentários quais tópicos você gostaria de ver explicados!

[pt-BR] Tratamento de Erros em Rust: Desmistificando Result e Option para Pythonistas

Jose Luis da Cruz Junior — Tue, 01 Sep 2026 11:00:00 +0000

Por @zejuniortdr em Mar 21, 2026

👋 Bem-vindos, desbravadores! Hoje vamos explorar um dos aspectos mais poderosos e característicos de Rust: seu sistema de tratamento de erros. Se você vem do Python, onde usamos exceções para quase tudo, prepare-se para uma abordagem mais segura e explícita que vai mudar sua forma de pensar sobre erros.

Introdução: Por Que Rust Faz Diferente?

No Python, estamos acostumados com o clássico try/except - lançamos exceções quando algo dá errado e as capturamos quando queremos lidar com os problemas. É prático, mas também propenso a erros: podemos facilmente esquecer de tratar um erro ou deixar escapar exceções inesperadas.

Rust toma um caminho diferente: erros são tratados como valores, não como exceções controladas. Isso significa que o compilador nos força a lidar com possíveis falhas explicitamente, tornando nosso código mais seguro e previsível.

Vamos comparar as duas abordagens:

Python: Exceções (try/except/finally)
Rust: Tipos enumerados (Result e Option) + pattern matching

🧩 Seção 1: Entendendo Option - O Equivalente ao None do Python

Em Python, usamos None para representar a ausência de valor. Em Rust, temos Option<T>, que é muito mais poderoso e seguro.

Option Explicado para Pythonistas

Option<T> é um enum (tipo enumerado) que pode ser:

Some(T) - contém um valor do tipo T
None - não contém nenhum valor

Vejamos a diferença na prática:

# Python: Função que pode retornar None
def encontrar_primeiro_par(numeros):
    for num in numeros:
        if num % 2 == 0:
            return num
    return None

# Uso (podemos esquecer de verificar None)
resultado = encontrar_primeiro_par([1, 3, 5])
if resultado is not None:
    print(f"Encontrado: {resultado}")
else:
    print("Nenhum par encontrado")

// Rust: Função que retorna Option<i32>
fn encontrar_primeiro_par(numeros: &[i32]) -> Option<i32> {
    for &num in numeros {
        if num % 2 == 0 {
            return Some(num); // Temos um valor
        }
    }
    None // Nenhum valor encontrado
}

// Uso (o compilador nos força a tratar ambos os casos)
fn main() {
    let numeros = vec![1, 3, 5];
    match encontrar_primeiro_par(&numeros) {
        Some(num) => println!("Encontrado: {}", num),
        None => println!("Nenhum par encontrado"),
    }
}

A grande vantagem do Option é que o compilador não deixa você esquecer de tratar o caso None. Em Python, é fácil esquecer de verificar se um valor é None - em Rust, isso é impossível.

Métodos Úteis do Option

Rust oferece vários métodos para trabalhar com Option de forma concisa:

let valor_some = Some(42);
let valor_none: Option<i32> = None;

// unwrap(): obtém o valor ou entra em pânico se for None (⚠️ perigoso!)
println!("{}", valor_some.unwrap()); // 42
// println!("{}", valor_none.unwrap()); // PANIC!

// unwrap_or(): valor padrão se for None
println!("{}", valor_none.unwrap_or(0)); // 0

// map(): transforma o valor se for Some
let valor_dobrado = valor_some.map(|x| x * 2); // Some(84)

// and_then(): transforma e "achata" o resultado
let resultado = valor_some.and_then(|x| Some(x * 2)); // Some(84)

🎯 Seção 2: Dominando Result - Uma Alternativa às Exceções

Enquanto Option lida com a ausência de valor, Result<T, E> lida com operações que podem falhar. É o equivalente rusticano das exceções do Python, mas muito mais seguro.

Result Explicado

Result é um enum com duas variantes:

Ok(T) - operação bem-sucedida, contém o resultado
Err(E) - operação falhou, contém informação do erro

Vamos comparar com Python:

# Python: Divisão com possível exceção
def dividir(a, b):
    if b == 0:
        raise ValueError("Não pode dividir por zero!")
    return a / b

# Uso (podemos esquecer de capturar a exceção)
try:
    resultado = dividir(10, 0)
    print(f"Resultado: {resultado}")
except ValueError as e:
    print(f"Erro: {e}")

// Rust: Divisão com Result
fn dividir(a: f64, b: f64) -> Result<f64, String> {
    if b == 0.0 {
        return Err("Não pode dividir por zero!".to_string());
    }
    Ok(a / b)
}

// Uso (devemos tratar ambos os casos)
fn main() {
    match dividir(10.0, 0.0) {
        Ok(resultado) => println!("Resultado: {}", resultado),
        Err(erro) => println!("Erro: {}", erro),
    }
}

Tipos de Erro Personalizados

Em Rust, podemos (e devemos!) criar nossos próprios tipos de erro:

// Definindo um tipo de erro personalizado
#[derive(Debug)]
enum ErroMatematico {
    DivisaoPorZero,
    RaizNegativa,
    Overflow,
}

// Implementando mensagem de erro
impl std::fmt::Display for ErroMatematico {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        match self {
            ErroMatematico::DivisaoPorZero => write!(f, "Divisão por zero"),
            ErroMatematico::RaizNegativa => write!(f, "Raiz quadrada de número negativo"),
            ErroMatematico::Overflow => write!(f, "Overflow matemático"),
        }
    }
}

// Função que usa nosso erro personalizado
fn dividir_seguro(a: f64, b: f64) -> Result<f64, ErroMatematico> {
    if b == 0.0 {
        return Err(ErroMatematico::DivisaoPorZero);
    }
    Ok(a / b)
}

🧰 Seção 3: Pattern Matching e Operador ? para Tratamento Conciso

Pattern Matching: O Poderoso Match

O match é uma das ferramentas mais poderosas de Rust para tratar Option e Result:

fn processar_resultado(resultado: Result<i32, String>) {
    match resultado {
        Ok(valor) => {
            println!("Sucesso! Valor: {}", valor);
            // Podemos fazer mais processamento aqui
        },
        Err(erro) => {
            println!("Falha! Erro: {}", erro);
            // Podemos tratar o erro ou propagar
        }
    }
}

// Match também funciona com Option
fn processar_option(opcao: Option<String>) {
    match opcao {
        Some(texto) => println!("Texto: {}", texto),
        None => println!("Nenhum texto fornecido"),
    }
}

Operador ?: Propagação de Erros Simplificada

O operador ? é uma das características mais convenientes de Rust. Ele propaga erros automaticamente:

// Sem o operador ? (mais verboso)
fn ler_arquivo_caminho(caminho: &str) -> Result<String, std::io::Error> {
    let arquivo_resultado = std::fs::File::open(caminho);

    let mut arquivo = match arquivo_resultado {
        Ok(arquivo) => arquivo,
        Err(erro) => return Err(erro),
    };

    let mut conteudo = String::new();
    match std::io::Read::read_to_string(&mut arquivo, &mut conteudo) {
        Ok(_) => Ok(conteudo),
        Err(erro) => Err(erro),
    }
}

// Com o operador ? (muito mais limpo!)
fn ler_arquivo_caminho_simples(caminho: &str) -> Result<String, std::io::Error> {
    let mut arquivo = std::fs::File::open(caminho)?;
    let mut conteudo = String::new();
    std::io::Read::read_to_string(&mut arquivo, &mut conteudo)?;
    Ok(conteudo)
}

// Podemos ainda simplificar mais com métodos de conveniência
fn ler_arquivo_mais_simples(caminho: &str) -> Result<String, std::io::Error> {
    std::fs::read_to_string(caminho)
}

🔄 Seção 4: Como as Exceções do Python se Comparam com Rust

Diferenças Fundamentais

Característica	Python	Rust
Propagação	Automática (call stack)	Manual (com `?`)
Verificação	Em runtime	Em tempo de compilação
Obrigatoriedade	Opcional tratar	Obrigatório tratar
Performance	Custo alto (stack unwinding)	Custo zero (erros são valores)

Quando Usar Cada Abordagem

Em Python, use exceções para:

Erros verdadeiramente excepcionais (raros)
Quando quer propagar automaticamente pela call stack
Em código onde performance não é crítica

Em Rust, use Result/Option para:

Erros esperados (comuns na lógica do programa)
Quando quer controle explícito sobre o fluxo de erro
Em código onde performance e segurança são importantes

Exemplo Prático Completo: Processador de Configurações

Vamos ver um exemplo completo que processa um arquivo de configuração:

# Python: Processador de configuração com exceções
import json

def carregar_configuracao(caminho):
    try:
        with open(caminho, 'r') as arquivo:
            config = json.load(arquivo)

        if 'porta' not in config:
            raise ValueError("Porta não especificada na configuração")

        if not isinstance(config['porta'], int):
            raise TypeError("Porta deve ser um número inteiro")

        return config

    except FileNotFoundError:
        print(f"Arquivo {caminho} não encontrado")
        return {"porta": 8080}  # Valor padrão
    except json.JSONDecodeError:
        print("Erro ao decodificar JSON")
        return {"porta": 8080}
    except (ValueError, TypeError) as e:
        print(f"Erro de configuração: {e}")
        return {"porta": 8080}

# Uso
config = carregar_configuracao("config.json")
print(f"Porta: {config['porta']}")

// Rust: Processador de configuração com Result
use std::fs;
use serde::Deserialize; // ⚠️ Necessário adicionar serde no Cargo.toml

#[derive(Debug, Deserialize)]
struct Configuracao {
    porta: u16,
}

// Definimos nossos tipos de erro
#[derive(Debug)]
enum ErroConfiguracao {
    ArquivoNaoEncontrado,
    ParseErro,
    PortaNaoEspecificada,
    PortaInvalida,
}

// Implementamos tratamento de erro personalizado
impl std::fmt::Display for ErroConfiguracao {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        match self {
            ErroConfiguracao::ArquivoNaoEncontrado => write!(f, "Arquivo não encontrado"),
            ErroConfiguracao::ParseErro => write!(f, "Erro ao analisar JSON"),
            ErroConfiguracao::PortaNaoEspecificada => write!(f, "Porta não especificada"),
            ErroConfiguracao::PortaInvalida => write!(f, "Porta deve ser um número válido"),
        }
    }
}

fn carregar_configuracao(caminho: &str) -> Result<Configuracao, ErroConfiguracao> {
    // Usamos ? para propagar erros automaticamente
    let conteudo = fs::read_to_string(caminho)
        .map_err(|_| ErroConfiguracao::ArquivoNaoEncontrado)?;

    // Parse do JSON com tratamento de erro
    let config: Configuracao = serde_json::from_str(&conteudo)
        .map_err(|_| ErroConfiguracao::ParseErro)?;

    // Validação adicional
    if config.porta == 0 {
        return Err(ErroConfiguracao::PortaInvalida);
    }

    Ok(config)
}

// Função principal com tratamento de erro
fn main() {
    match carregar_configuracao("config.json") {
        Ok(config) => println!("Porta: {}", config.porta),
        Err(ErroConfiguracao::ArquivoNaoEncontrado) => {
            println!("Usando configuração padrão (porta 8080)");
            let config_default = Configuracao { porta: 8080 };
            println!("Porta: {}", config_default.porta);
        },
        Err(erro) => {
            println!("Erro na configuração: {}. Usando padrão (porta 8080)", erro);
            let config_default = Configuracao { porta: 8080 };
            println!("Porta: {}", config_default.porta);
        }
    }
}

⚠️ Erros Comuns de Pythonistas em Rust

Esquecer de tratar Option/Result: O compilador vai te avisar, mas inicialmente é frustrante!
Usar unwrap() demais: É tentador, mas não é tratamento de erro de verdade!
Não usar o operador ?: Pythonistas tendem a usar match excessivamente no início
Criar tipos de erro complexos: Comece simples, depois evolua conforme a necessidade
Ignorar os erros de bibliotecas: Em Rust, quase todas as operações de I/O retornam Result

🎓 O que Aprendemos

Option é o equivalente seguro do None do Python, forçando tratamento explícito
Result substitui exceções com verificação em tempo de compilação
Pattern matching com match oferece controle preciso sobre o fluxo de erros
Operador ? simplifica a propagação de erros de forma segura
Erros customizados permitem criar hierarquias de erro específicas para sua aplicação
Rust exige mais boilerplate inicialmente, mas resulta em código muito mais seguro

O sistema de erros de Rust pode parecer verboso no início, especialmente vindo do Python, mas essa "verborragia" é na verdade explícita documentação em tempo de compilação. O compilator é seu amigo aqui, garantindo que você nunca se esqueça de tratar um erro possível.

📚 Próximos Passsos

Quer se aprofundar ainda mais em Rust? O livro "Desbravando Rust" cobre esses e muitos outros conceitos com exemplos práticos, exercícios e projetos reais.

Visite nosso site desbravandorust.com.br para adquirir seu exemplar e continuar sua jornada na linguagem mais amada pela comunidade!

Nos próximos posts, vamos explorar concorrência em Rust, sistemas de tipos avançados, e como interoperar Rust com Python. Até lá! 🚀

Artigo publicado no blog Desbravando Rust - Material de apoio para o livro "Desbravando Rust"

[pt-BR] Dominando Enums em Rust: Do Básico ao Avançado para Pythonistas

Jose Luis da Cruz Junior — Tue, 25 Aug 2026 11:00:00 +0000

Por @zejuniortdr em Mar 14, 2026

🦀🔍 Se você vem do Python, enums (ou "enumerações") podem parecer apenas uma forma elegante de definir constantes. Mas em Rust, eles são uma superpotência! Neste post, vamos explorar como os enums em Rust vão muito além do que você está acostumado no Python, permitindo associar dados, implementar métodos e usar pattern matching de forma poderosa.

Introdução: Enums no Python vs Rust

Em Python, enums são principalmente usados para definir conjuntos de constantes relacionadas. Veja um exemplo básico:

from enum import Enum

class DiaDaSemana(Enum):
    SEGUNDA = 1
    TERCA = 2
    QUARTA = 3
    # ... e assim por diante

Isso é útil para organizar constantes e evitar "números mágicos" no código. Mas em Rust, os enums podem fazer muito mais!

Rust expande o conceito de enums para:

Associar dados diretamente às variantes
Implementar métodos (como em structs)
Usar pattern matching exaustivo
Ser a base para sistemas de erro (Result) e opcionais (Option)

Seção 1: Enums Básicos em Rust - Similar ao Python

Vamos começar com o equivalente em Rust ao enum Python que vimos:

// Definindo um enum básico
enum DiaDaSemana {
    Segunda,
    Terca,
    Quarta,
    Quinta,
    Sexta,
    Sabado,
    Domingo,
}

// Usando o enum
let hoje = DiaDaSemana::Segunda;

Até aqui, parece bem similar ao Python. Mas mesmo nesse caso simples, Rust oferece vantagens:

Segurança de tipos: O compilador sabe exatamente todos os valores possíveis
Sem overhead: Enums em Rust são otimizados, muitas vezes usando apenas um byte
Pattern matching nativo (veremos mais adiante)

Seção 2: Enums Avançados - Associando Dados e Métodos

🚀 Aqui é onde Rust brilha! Enums podem carregar dados adicionais em cada variante. Vamos criar um enum para representar diferentes tipos de eventos em um sistema:

// Enum com dados associados
enum Evento {
    Login { usuario: String, hora: String },
    Logout { usuario: String },
    AcessoRecurso { usuario: String, recurso: String, status: u16 },
}

// Criando instâncias
let evento1 = Evento::Login {
    usuario: String::from("joao"),
    hora: String::from("10:00"),
};

let evento2 = Evento::AcessoRecurso {
    usuario: String::from("maria"),
    recurso: String::from("/dashboard"),
    status: 200,
};

Em Python, precisaríamos usar classes e herança para algo similar:

from dataclasses import dataclass

@dataclass
class Login:
    usuario: str
    hora: str

@dataclass
class Logout:
    usuario: str

@dataclass
class AcessoRecurso:
    usuario: str
    recurso: str
    status: int

# Uso
evento1 = Login(usuario="joao", hora="10:00")
evento2 = AcessoRecurso(usuario="maria", recurso="/dashboard", status=200)

Diferenças importantes:

Em Rust, todos os casos estão sob o mesmo tipo Evento
O compilador Rust vai forçar você a lidar com todos os casos possíveis
A representação em memória é mais eficiente em Rust

Implementando Métodos

Assim como structs, enums em Rust podem ter métodos:

impl Evento {
    fn get_usuario(&self) -> &str {
        match self {
            Evento::Login { usuario, .. } => usuario,
            Evento::Logout { usuario } => usuario,
            Evento::AcessoRecurso { usuario, .. } => usuario,
        }
    }
}

// Uso
println!("Usuário do evento: {}", evento1.get_usuario());

Seção 3: Pattern Matching com Enums - Poder Além do if-elif-else

🔥 Pattern matching é onde os enums de Rust realmente brilham. Vamos comparar como lidaríamos com nosso enum Evento em Python vs Rust.

Em Python (usando if-elif e isinstance):

def processar_evento(evento):
    if isinstance(evento, Login):
        print(f"Usuário {evento.usuario} fez login às {evento.hora}")
    elif isinstance(evento, Logout):
        print(f"Usuário {evento.usuario} fez logout")
    elif isinstance(evento, AcessoRecurso):
        print(f"Acesso a {evento.recurso} com status {evento.status}")
    else:
        raise ValueError("Tipo de evento desconhecido")

Em Rust (usando match):

fn processar_evento(evento: Evento) {
    match evento {
        Evento::Login { usuario, hora } => {
            println!("Usuário {} fez login às {}", usuario, hora);
        }
        Evento::Logout { usuario } => {
            println!("Usuário {} fez logout", usuario);
        }
        Evento::AcessoRecurso { usuario, recurso, status } => {
            println!("Acesso a {} com status {}", recurso, status);
        }
    }
}

Vantagens do pattern matching em Rust:

Exaustividade: O compilador verifica se todos os casos foram tratados
Desestruturação: Podemos extrair valores diretamente no match
Concisão: Muito mais limpo que vários if-elif

Exemplo Avançado com Match

Vamos criar um sistema de autenticação que trata diferentes erros:

enum ErroAutenticacao {
    UsuarioNaoEncontrado,
    SenhaIncorreta,
    ContaBloqueada,
    LimiteTentativas,
}

fn tratar_erro(erro: ErroAutenticacao) -> String {
    match erro {
        ErroAutenticacao::UsuarioNaoEncontrado => "Usuário não cadastrado".to_string(),
        ErroAutenticacao::SenhaIncorreta => "Senha incorreta".to_string(),
        ErroAutenticacao::ContaBloqueada => "Conta bloqueada - contate o suporte".to_string(),
        ErroAutenticacao::LimiteTentativas => "Muitas tentativas - espere 5 minutos".to_string(),
    }
}

Comparação com Python: Quando Usar Enums

Em Python, enums são úteis para:

Definir constantes relacionadas
Melhorar legibilidade do código
Evitar strings/números mágicos

Em Rust, enums devem ser usados para:

Representar estados mutuamente exclusivos
Sistemas de erro (como Result e Option)
Máquinas de estado
Dados que podem ter diferentes "formatos"

💡 Dica para Pythonistas: Pense em enums Rust como uma combinação de enums Python + classes + unions types + pattern matching!

Erros Comuns de Pythonistas em Rust

Esquecer de tratar todos os casos no match:
- Rust força você a tratar todas as variantes
- Solução: Use _ => {} ou trate explicitamente cada caso
Tentar usar enums Rust como dicionários Python:
- Enums não são estruturas de dados flexíveis
- Para dados dinâmicos, considere structs ou enums com dados associados
Subestimar a capacidade de associação de dados:
- Em Python, é comum usar classes separadas
- Em Rust, enums com dados são mais idiomáticos

Exemplo Prático: Sistema de Arquivos Simulado

Vamos criar um sistema que representa diferentes tipos de arquivos:

enum SistemaArquivosItem {
    Arquivo {
        nome: String,
        tamanho: u64,
        extensao: String,
    },
    Diretorio {
        nome: String,
        itens: Vec<SistemaArquivosItem>,
    },
    LinkSimbolico {
        nome: String,
        destino: String,
    },
}

impl SistemaArquivosItem {
    fn calcular_tamanho(&self) -> u64 {
        match self {
            SistemaArquivosItem::Arquivo { tamanho, .. } => *tamanho,
            SistemaArquivosItem::Diretorio { itens, .. } => {
                itens.iter().map(|item| item.calcular_tamanho()).sum()
            }
            SistemaArquivosItem::LinkSimbolico { .. } => 0,
        }
    }
}

// Uso
let root = SistemaArquivosItem::Diretorio {
    nome: "root".to_string(),
    itens: vec![
        SistemaArquivosItem::Arquivo {
            nome: "foto.jpg".to_string(),
            tamanho: 1024,
            extensao: "jpg".to_string(),
        },
        SistemaArquivosItem::LinkSimbolico {
            nome: "atalho".to_string(),
            destino: "/outro/lugar".to_string(),
        },
    ],
};

println!("Tamanho total: {}", root.calcular_tamanho());

O que aprendemos

🎯 Enums em Rust vão muito além de simples constantes
🔗 Podem associar dados diretamente às variantes
🧩 Pattern matching permite lidar com todos os casos de forma segura
⚙️ Podem implementar métodos como structs
🐍 São mais poderosos que enums Python, substituindo vários padrões
🛡️ O compilador garante que todos os casos sejam tratados

Conclusão: Por que enums são essenciais em Rust

Enums são uma das características mais poderosas de Rust, permitindo modelar domínios complexos de forma segura e eficiente. Para Pythonistas, pode parecer estranho no começo, mas logo você vai perceber como eles tornam seu código mais expressivo e seguro.

Quer se aprofundar ainda mais em Rust? Confira nosso livro "Desbravando Rust" com muito mais conteúdo para quem vem do Python: desbravandorust.com.br

[pt-BR] Gerenciamento de Memória em Rust vs Python: Alocação e Desempenho

Jose Luis da Cruz Junior — Tue, 18 Aug 2026 11:00:00 +0000

Por @zejuniortdr em Fev 28, 2026

🔍 Imagine que a memória do computador é como uma grande biblioteca. Em Python, temos um bibliotecário (o Garbage Collector) que fica organizando os livros (objetos) para nós. Já em Rust, somos nós mesmos os bibliotecários, mas com regras muito claras sobre quem pode pegar qual livro e quando devolver. Vamos desvendar essas diferenças fundamentais!

Introdução: Duas Filosofias, Dois Mundos

Na programação, gerenciamento de memória é como administrar os recursos de uma cidade:

Python é como uma cidade com serviço de coleta automática de lixo. Conveniente, mas às vezes o caminhão passa na hora errada.
Rust é como uma cidade onde cada morador é responsável por seu próprio lixo, com regras rígidas para evitar sujeira.

Vamos explorar como essas abordagens impactam desempenho, segurança e produtividade.

🐍 Seção 1: O Mundo Python - Garbage Collector e Referências

Python usa um sistema automático de gerenciamento de memória baseado em:

Contagem de referências: Cada objeto sabe quantas variáveis apontam para ele
Garbage Collector (GC): Um mecanismo que identifica e limpa objetos não acessíveis

# Exemplo de alocação em Python
lista = [1, 2, 3]  # Aloca memória para a lista
outra_ref = lista   # Cria nova referência para o mesmo objeto
del lista           # Remove uma referência, mas o objeto persiste
# O GC eventualmente limpará a memória quando não houver mais referências

Problema clássico em Python:

# Ciclo de referências que o GC precisa resolver
class Node:
    def __init__(self, value):
        self.value = value
        self.next = None

a = Node(1)
b = Node(2)
a.next = b
b.next = a  # Ciclo criado!

# Mesmo sem referências externas, o GC precisa intervir
del a
del b

Vantagens do modelo Python:

✅ Simplicidade: o programador não precisa pensar em liberar memória
✅ Produtividade: foco na lógica de negócios

Desvantagens:

❌ Imprevisibilidade: não sabemos quando o GC vai rodar
❌ Overhead: o GC consome recursos do sistema

🦀 Seção 2: O Modelo Rust - Ownership e Borrowing

Rust introduz um sistema único de propriedade (ownership) com 3 regras fundamentais:

Cada valor em Rust tem um dono (owner)
Só pode haver um dono por vez
Quando o dono sai de escopo, o valor é liberado

// Exemplo básico de ownership
fn main() {
    let s = String::from("hello");  // s é o dono da String
    faz_algo(s);                    // Transfere a propriedade para a função

    // println!("{}", s);          // ERRO! s não é mais dono do valor
}

fn faz_algo(texto: String) {        // texto agora é o novo dono
    println!("{}", texto);
}                                   // texto sai de escopo e a memória é liberada

Borrowing (empréstimo): Quando não queremos transferir a propriedade:

fn main() {
    let s = String::from("hello");
    pega_emprestado(&s);            // Empresta uma referência imutável
    println!("{}", s);              // OK! s ainda é o dono
}

fn pega_emprestado(texto: &String) { // Recebe uma referência
    println!("{}", texto);
}

🔄 Comparação Direta: Python vs Rust

Vamos implementar um exemplo prático em ambas as linguagens:

Cenário: Processar um grande conjunto de dados sem desperdiçar memória

Versão Python:

def processar_dados():
    dados = [x for x in range(1_000_000)]  # Aloca lista grande

    # Modifica os dados
    resultados = [x * 2 for x in dados]

    # Liberação da memória depende do GC
    return resultados

resultado = processar_dados()
# Quando 'resultado' não for mais usado, o GC liberará a memória

Versão Rust:

fn processar_dados() -> Vec<i32> {
    let dados: Vec<i32> = (1..1_000_000).collect();  // Aloca vetor

    // Consome 'dados' e produz novo vetor
    let resultados: Vec<i32> = dados.into_iter().map(|x| x * 2).collect();

    // 'dados' foi movido e liberado automaticamente
    resultados
}  // 'resultados' será liberado quando sair do escopo do chamador

fn main() {
    let resultado = processar_dados();
    // Memória gerenciada de forma previsível
}

Principais diferenças:
| Característica | Python | Rust |
|----------------------|-------------------------|--------------------------|
| Modelo | Garbage Collected | Ownership based |
| Controle | Automático | Manual (com segurança) |
| Previsibilidade | Baixa | Alta |
| Overhead | Alto (GC) | Praticamente zero |
| Segurança | Possíveis vazamentos | Garantida em tempo de compilação |

🚨 Erros Comuns de Pythonistas em Rust

Tentar modificar dados emprestados:

let mut s = String::from("hello");
let ref1 = &s;
let ref2 = &mut s;  // ERRO! Não pode ter referência mutável enquanto há imutáveis

Assumir que cópias são baratas como em Python:

let s1 = String::from("texto grande");
let s2 = s1;  // Em Rust isso MOVE, não copia (a menos que implemente Clone)

Esquecer que escopos determinam lifetime:

let r;
{
    let x = 5;
    r = &x;  // ERRO! x não vive o suficiente
}

🔍 Exemplo Prático Completo: Processador de Dados

Vamos implementar um sistema mais complexo em ambas as linguagens:

Python (com gerenciamento manual):

class DataProcessor:
    def __init__(self):
        self.cache = {}

    def process(self, data):
        # Verifica cache primeiro
        if id(data) in self.cache:
            return self.cache[id(data)]

        # Processamento pesado
        result = [x ** 2 for x in data]

        # Guarda no cache (cuidado com memory leak!)
        self.cache[id(data)] = result
        return result

# Uso
processor = DataProcessor()
dados = list(range(100000))
resultado = processor.process(dados)
del dados  # Importante para liberar memória

Rust (com segurança garantida):

use std::collections::HashMap;

struct DataProcessor {
    cache: HashMap<usize, Vec<i32>>,
}

impl DataProcessor {
    fn new() -> Self {
        DataProcessor {
            cache: HashMap::new(),
        }
    }

    fn process(&mut self, data: &[i32]) -> &Vec<i32> {
        let data_ptr = data.as_ptr() as usize;

        // Verifica cache primeiro (usando entry API para eficiência)
        self.cache.entry(data_ptr)
            .or_insert_with(|| data.iter().map(|&x| x.pow(2)).collect())
    }
}

fn main() {
    let mut processor = DataProcessor::new();
    let dados: Vec<i32> = (0..100000).collect();
    let resultado = processor.process(&dados);

    // Memória gerenciada automaticamente com garantias
}

Análise:

Python requer cuidado manual para evitar memory leaks no cache
Rust garante segurança de memória em tempo de compilação
A versão Rust é mais performática (sem GC, alocações previsíveis)

📊 Quando Escolher Cada Abordagem

Prefira Python quando:

Desenvolvimento rápido é prioritário
O time não tem experiência com gerenciamento manual de memória
A aplicação não é crítica para desempenho

Prefira Rust quando:

Desempenho e previsibilidade são essenciais
Você precisa de garantias de segurança de memória
O sistema opera com recursos limitados (IoT, embarcados)

🎯 O que aprendemos

✔ Python usa Garbage Collector automático enquanto Rust usa ownership
✔ Contagem de referências vs verificação em tempo de compilação
✔ Rust oferece melhor desempenho e previsibilidade na gestão de memória
✔ Python prioriza produtividade em detrimento do controle fino
✔ O modelo de ownership previne bugs comuns como dangling pointers
✔ Borrowing em Rust permite segurança sem sacrificar flexibilidade

📚 Quer Aprofundar em Rust?

Este post é apenas um aperitivo do conteúdo completo que oferecemos no livro "Desbravando Rust"! Se você quer:

Dominar o sistema de ownership na prática
Aprender a escrever código seguro e performático
Fazer a transição suave de Python para Rust

Visite nosso site em desbravandorust.com.br e garanta seu exemplar hoje mesmo! 🚀

Próximo post: "Concorrência em Rust vs Python: Threads, async e além". Não perca!

[pt-BR] Entendendo Ownership em Rust: Um Guia para Pythonistas

Jose Luis da Cruz Junior — Tue, 11 Aug 2026 11:00:00 +0000

Por @zejuniortdr em Fev 22, 2026

Se você vem do Python e está começando com Rust, provavelmente já se deparou com mensagens de erro misteriosas sobre "ownership", "borrowing" ou "value moved here". Calma, você não está sozinho nessa jornada. Vamos explorar juntos esse conceito que é o coração da segurança e performance do Rust.

Por que Ownership é tão importante em Rust?

Imagine que você está organizando uma festa na sua casa — sua memória RAM é a casa. Em Python, é como se você tivesse um assistente (o coletor de lixo) que fica anotando quem veio, quem saiu e limpando tudo depois. Já em Rust, você é o anfitrião responsável: precisa garantir que cada convidado (dado) tenha um lugar certo, sem bagunça e sem invasores.

Esse sistema permite ao Rust:

Garantir segurança de memória sem coletor de lixo
Prevenir vazamentos de memória e acessos inválidos
Permitir otimizações de performance em tempo de compilação

Os três princípios do Ownership

Direto do livro oficial do Rust, as regras são:

Cada valor em Rust tem um dono (owner)
Só pode haver um dono por vez
Quando o dono sai de escopo, o valor é descartado

Parece simples, mas as implicações são profundas. Vamos entender com exemplos.

Princípio 1: Cada valor tem um dono

Em Rust, toda variável é dona do valor que armazena:

fn main() {
    let s = String::from("hello");  // s é a dona da String "hello"
    println!("{}", s);              // podemos usar s aqui
} // s sai de escopo e a memória é liberada automaticamente

Compare com Python, onde os objetos têm vida própria:

def main():
    s = "hello"  # s referencia o objeto string
    print(s)     # mas não é sua "dona" exclusiva
    # O coletor de lixo decide quando liberar a memória

Princípio 2: Um único dono por vez

Em Rust, você não pode ter múltiplos donos para o mesmo valor. Note também que tipos simples como inteiros e booleanos implementam o trait Copy e não sofrem move — são copiados automaticamente:

fn main() {
    // Tipos que implementam Copy são copiados, não movidos
    let x = 5;
    let y = x;
    println!("{} {}", x, y); // Ok: i32 implementa Copy

    // String NÃO implementa Copy: sofre move
    let s1 = String::from("hello");
    let s2 = s1; // O valor é MOVIDO de s1 para s2

    // println!("{}", s1); // ERRO! s1 não é mais dona de nada
    println!("{}", s2);    // Ok, s2 é a nova dona
}

Em Python, isso seria perfeitamente válido em ambos os casos:

s1 = "hello"
s2 = s1  # Ambos referenciam o mesmo objeto
print(s1)  # Funciona
print(s2)  # Funciona

Princípio 3: Descarte quando sai de escopo

Rust automaticamente libera memória quando o dono sai de escopo. Quando isso acontece, o compilador chama implicitamente o trait Drop do valor — o equivalente a um destrutor que você pode até customizar para seus próprios tipos:

fn main() {
    let outer = String::from("outer");
    {
        // Novo escopo
        let inner = String::from("inner");
        println!("{}", outer); // Ok
        println!("{}", inner); // Ok
    } // inner é dropada aqui; Drop é chamado automaticamente

    // println!("{}", inner); // ERRO! inner não existe mais aqui
    println!("{}", outer);    // outer ainda é válida
}

Em Python, não temos essa garantia imediata:

def main():
    s = "hello"
    print(s)
    # O objeto pode ou não ser liberado imediatamente
    # Depende do coletor de lixo

Erros comuns de Pythonistas em Rust

Agora que vimos os princípios, vamos aos problemas que você provavelmente enfrentará.

1. Tentar usar uma variável após movê-la

let s1 = String::from("texto");
let s2 = s1;
println!("{}", s1);  // ERRO: value borrowed here after move

Solução: Use referências (&) ou clone explicitamente:

let s1 = String::from("texto");
let s2 = &s1; // Empresta s1 sem mover
println!("{} {}", s1, s2); // Ok

2. Modificar uma referência imutável

Este erro é sutil: o problema não é só tentar modificar uma referência imutável, mas tentar criar uma referência mutável enquanto referências imutáveis ainda estão ativas:

let mut s = String::from("hello");
let r = &s;              // Referência imutável ativa
s.push_str(", world");   // ERRO: cannot borrow `s` as mutable
                         // because it is also borrowed as immutable
println!("{}", r);

Solução: Use referências mutáveis somente quando não há referências imutáveis ativas:

let mut s = String::from("hello");
// Não há referências imutáveis ativas aqui
let r = &mut s;
r.push_str(", world"); // Ok
println!("{}", r);

3. Criar referências inválidas (dangling references)

fn cria_referencia() -> &String {
    let s = String::from("hello");
    &s // ERRO: s será liberada ao final da função!
}

Solução: Retorne o valor diretamente, transferindo ownership para quem chamou:

fn cria_string() -> String {
    let s = String::from("hello");
    s // Transfere ownership para o caller
}

Exemplo prático completo:

Vamos ver um exemplo completo que mostra ownership na prática, comparando Rust e Python:

Versão Rust

fn main() {
    // Passamos ownership para a função; original não pode ser usada depois
    let original = String::from("Rust é seguro");
    let comprimento = calcula_comprimento(original);
    println!("Comprimento: {}", comprimento);
    // println!("{}", original); // ERRO: original foi movida

    // Com borrowing, original permanece válida
    let original2 = String::from("Rust é eficiente");
    let comprimento2 = calcula_comprimento_emprestado(&original2);
    println!("Original2 ainda válida: {}", original2);
    println!("Comprimento: {}", comprimento2);

    // Clone cria uma cópia real e independente
    let copia = original2.clone();
    let comprimento3 = calcula_comprimento(copia);
    println!("Original2 ainda válida: {}", original2);
    println!("Comprimento da cópia: {}", comprimento3);
}

// Recebe ownership da String; ela é liberada ao final
fn calcula_comprimento(s: String) -> usize {
    s.len()
}

// Recebe uma referência; usa &str para ser mais idiomático
fn calcula_comprimento_emprestado(s: &str) -> usize {
    s.len()
}

Versão Python

def main():
    original = "Python é dinâmico"

    # Em Python, passamos referências, não ownership
    comprimento = calcula_comprimento(original)

    # Original ainda está acessível
    print(f"Original: {original}")

    # Não precisamos nos preocupar com borrowing ou moving
    original2 = "Python é flexível"
    comprimento2 = calcula_comprimento(original2)
    print(f"Original2 ainda válida: {original2}")

def calcula_comprimento(s):
    return len(s)  # Não afetamos o caller

Ownership em tipos customizados

O sistema de ownership se aplica igualmente a structs e outros tipos compostos. Sempre que uma struct contém um campo como String, ela também não implementa Copy — portanto sofre move na atribuição:

struct Item {
    nome: String,
}

fn main() {
    let item = Item { nome: String::from("Exemplo") };
    let item2 = item; // Move ocorre aqui

    // println!("{}", item.nome); // ERRO: item foi movido
    println!("{}", item2.nome);   // Ok
}

Comparação: Gerenciamento de memória em Python vs Rust

Característica	Python	Rust
Modelo	Coleta de lixo (GC)	Ownership system
Performance	Overhead do GC	Sem overhead de runtime
Segurança	Possíveis referências inválidas	Garantido em tempo de compilação
Controle	Automático	Manual (com garantias)
Concorrência	GIL pode ser limitante	Sem GIL, seguro por design

Semântica de operações: Python vs Rust

Operação	Python	Rust
Atribuição (=)	Cria nova referência	Move ou copia (Copy types)
Cópia profunda	copy.deepcopy()	.clone()
Passagem para função	Por referência	Move ou borrow (&)

Quando usar clone() em Rust?

Pythonistas muitas vezes esperam que a atribuição crie cópias independentes. Em Rust, isso não acontece automaticamente para tipos alocados no heap. Se você precisa de uma cópia real, use clone() — mas use com consciência, pois ele aloca nova memória:

let s1 = String::from("texto");
let s2 = s1.clone(); // Cópia real, não só da referência

println!("s1 = {}, s2 = {}", s1, s2); // Ambos válidos

Em Python, isso seria equivalente a:

import copy
s1 = "texto"
s2 = copy.deepcopy(s1)  # Para strings é desnecessário, mas ilustra a ideia

Exercício prático

Para fixar o conceito, tente resolver o seguinte problema:

O código abaixo não compila. Modifique apenas a assinatura de exibe_tamanho para que nome permaneça válido após a chamada da função:

fn main() {
    let nome = String::from("Rustacean");
    exibe_tamanho(nome);
    println!("{}", nome); // Como fazer isso funcionar?
}

fn exibe_tamanho(s: String) {
    println!("Tamanho: {}", s.len());
}

Dica: a solução está na diferença entre mover e emprestar.

O que aprendemos? 📚

Ownership é o sistema único do Rust para gerenciar memória sem GC
Cada valor tem apenas um dono por vez em Rust
Quando o dono sai de escopo, o valor é liberado
Em Python, o coletor de lixo cuida da memória automaticamente
Erros comuns incluem tentar usar valores após movê-los
Referências (&) permitem "emprestar" valores sem transferir ownership
Clone() cria cópias reais quando necessário

Próximos passos na sua jornada Rust

Dominar ownership é o primeiro passo para escrever código Rust seguro e eficiente. No próximo post, exploraremos o conceito de borrowing e lifetimes em profundidade — incluindo como o compilador rastreia o tempo de vida das referências para garantir que nunca apontem para memória inválida.

Para se aprofundar ainda mais com exemplos práticos e exercícios, confira o livro Desbravando Rust em desbravandorust.com.br.

[pt-BR] De Django ORM para SQLx: A Jornada de um backend que desaprendeu a confiar em mágica

Jose Luis da Cruz Junior — Tue, 04 Aug 2026 11:00:00 +0000

Por @zejuniortdr em Fev 16, 2026

Este artigo é para quem viveu anos no conforto do Django ORM e está cogitando encarar SQLx em Rust. Vamos falar de produtividade, dor, performance e o que você realmente ganha (e perde) ao largar a ‘mágica’.

Passei quase 20 anos confiando que o Django fazia magia com bancos de dados. Eu estava errado - não era magia, era abstração. E abstrações, descobri da pior forma, têm custo.

Durante anos, escrevi código Python elegante que se transformava em SQL sem eu nem pensar nisso. Produto.objects.filter(preco__gt=100).select_related('categoria') - boom, query otimizada. Migrations automáticas com makemigrations. Admin de graça. CRUD em minutos. Era produtividade pura.

Até o dia em que isso deixou de ser verdade. Um endpoint de relatório começou a demorar 8 segundos. O Django Debug Toolbar mostrou 247 queries. Duzentas e quarenta e sete. Eu tinha acabado de criar o N+1 query mais épico da história da empresa, e o pior: o código Python parecia perfeitamente inocente. Foi quando comecei a questionar se eu realmente entendia o que estava acontecendo embaixo do capô.

E foi assim que acabei conhecendo SQLx. Minha primeira reação? "Mano, eu tenho que escrever SQL na mão?!" Spoiler: sim. E isso mudou completamente como penso sobre bancos de dados.

O Conforto (e o Preço) da Magia do Django ORM

Vamos ser justos: Django ORM é espetacular para o que foi projetado. Não estou aqui para fazer bashing - usei o Django por décadas e ainda uso em vários projetos. Mas preciso ser honesto sobre seus limites.

O Que o Django ORM Faz de Genial

A produtividade é absurda. Você define seus modelos como classes Python normais e ganha de graça:

# Django ORM - Elegante, Pythônico, Produtivo
from django.db import models

class Categoria(models.Model):
    nome = models.CharField(max_length=100)
    slug = models.SlugField(unique=True)

class Produto(models.Model):
    nome = models.CharField(max_length=200)
    descricao = models.TextField()
    preco = models.DecimalField(max_digits=10, decimal_places=2)
    estoque = models.IntegerField(default=0)
    categoria = models.ForeignKey(Categoria, on_delete=models.CASCADE)
    criado_em = models.DateTimeField(auto_now_add=True)

# Queries elegantes e intuitivas
produtos_caros = Produto.objects.filter(
    preco__gt=100,
    estoque__gt=0
).select_related('categoria')

# Lazy evaluation - não executa até você iterar
for produto in produtos_caros:
    print(f"{produto.nome} - {produto.categoria.nome}")

É lindo. É Pythônico. E funciona muito bem para 80% dos casos de uso. O sistema de migrations é quase mágico - você altera o modelo, roda makemigrations, e o Django gera o SQL de migração automaticamente. O admin? Um CRUD completo e funcional sem escrever uma linha de HTML.

Para MVPs, protótipos e aplicações CRUD tradicionais, Django ORM é imbatível em produtividade.

Onde a Magia Começa a Doer

Mas aí você começa a escalar. Suas queries ficam mais complexas. E começam os problemas:

1. N+1 Queries Silenciosos


# Parece inocente, mas...
produtos = Produto.objects.filter(estoque__gt=0)

for produto in produtos:
    print(produto.categoria.nome)  # BOOM! Uma query POR produto

Você precisa lembrar de usar select_related() ou prefetch_related(). Esqueça uma vez em produção e seu banco chora.

2. Queries Complexas Viram Hieróglifos

# Django ORM quando fica feio
from django.db.models import Count, Sum, F, Q, Prefetch

relatorio = Categoria.objects.annotate(
    total_produtos=Count('produto'),
    produtos_em_estoque=Count('produto', filter=Q(produto__estoque__gt=0)),
    valor_total_estoque=Sum(
        F('produto__preco') * F('produto__estoque')
    )
).filter(
    total_produtos__gt=5
).select_related(
    'categoria_pai'
).prefetch_related(
    Prefetch(
        'produto_set',
        queryset=Produto.objects.filter(estoque__gt=0).order_by('-preco')
    )
)

Olha, eu sei fazer isso. Mas na moral: você consegue ler essa query e saber exatamente qual SQL será gerado? Eu não consigo sem rodar e olhar o log.

3. Controle Limitado

Às vezes você sabe a query SQL perfeita. Você testou no psql, otimizou os índices, usou CTEs, tudo lindo. Mas fazer o Django gerar esse SQL específico? Boa sorte. Você acaba usando .raw() ou connection.cursor(), jogando fora todas as vantagens do ORM.

4. Performance Imprevisível

O ORM pode gerar SQL subótimo e você só descobre em produção, sob carga. Aquele inocente .filter().count() pode virar um SELECT COUNT(*) numa tabela de 10 milhões de linhas sem índice adequado.

O Choque Inicial com SQLx

Quando abri meu primeiro projeto Rust com SQLx, quase desliguei o pc e voltei para o conforto do Django.

// SQLx - Primeira impressão: "Isso é TUDO isso?!"
use sqlx::{PgPool, FromRow};
use serde::Serialize;

#[derive(Debug, FromRow, Serialize)]
struct Produto {
    id: i32,
    nome: String,
    preco: rust_decimal::Decimal,
    estoque: i32,
    categoria_id: i32,
}

async fn listar_produtos_caros(pool: &PgPool) -> Result<Vec<Produto>, sqlx::Error> {
    let produtos = sqlx::query_as::<_, Produto>(
        "SELECT id, nome, preco, estoque, categoria_id
         FROM produtos
         WHERE preco > $1 AND estoque > 0
         ORDER BY preco DESC"
    )
    .bind(100.0)
    .fetch_all(pool)
    .await?;

    Ok(produtos)
}

Minha reação: "Pera aí... eu tenho que escrever o SQL inteiro? Listar todos os campos? Não tem .select_related() mágico? E as migrations, onde estão?!"

Era desconfortável. Parecia que eu estava regredindo 15 anos na carreira.

Mas Aí Veio o Momento "Aha!"
Depois de alguns dias brigando com o compilador (porque Rust não perdoa), descobri algo incrível:


// SQLx com compile-time checking
let produtos = sqlx::query!(
    r#"
    SELECT id, nome, preco, estoque, categoria_id
    FROM produtos
    WHERE preco > $1 AND estoque > 0
    "#,
    100.0
)
.fetch_all(pool)
.await?;

// O compilador VALIDA essa query contra seu banco REAL
// Se você escreveu "produtoss" (com S duplo), NÃO COMPILA
// Se você typar "categoria_idd", NÃO COMPILA
// Se a coluna não existir, NÃO COMPILA

// E o melhor: autocomplete perfeito!
let primeiro = &produtos[0];
println!("{}", primeiro.nome);  // ← IDE sabe que existe
// primeiro.campo_inexistente  // ← ERRO DE COMPILAÇÃO

Isso mudou tudo.

O SQLx valida suas queries em tempo de compilação contra o schema real do banco de dados. Você não descobre erro de SQL em produção, às 3h da manhã, com o CEO te ligando. Você descobre quando tenta compilar. É impossível deployar SQL quebrado.

Comparação Técnica: Lado a Lado

Aspecto	Django ORM	SQLx	Vencedor
Curva de Aprendizado	⭐⭐⭐⭐⭐ Muito fácil	⭐⭐ Requer SQL sólido	Django
Produtividade Inicial	⭐⭐⭐⭐⭐ CRUD em minutos	⭐⭐⭐ Mais boilerplate	Django
Controle sobre SQL	⭐⭐ Limitado	⭐⭐⭐⭐⭐ Total	SQLx
Type Safety	⭐⭐ Runtime (mypy ajuda)	⭐⭐⭐⭐⭐ Compile-time	SQLx
Performance	⭐⭐⭐ Boa com cuidado	⭐⭐⭐⭐⭐ Zero overhead	SQLx
Debugging	⭐⭐ SQL gerado obscuro	⭐⭐⭐⭐ Você escreveu	SQLx
Migrations	⭐⭐⭐⭐⭐ Automáticas	⭐⭐ Manuais (ferramentas)	Django
Queries Complexas	⭐⭐ Fica feio rápido	⭐⭐⭐⭐ SQL puro é melhor	SQLx
Admin/CRUD Grátis	⭐⭐⭐⭐⭐ Sim	⭐ Não existe	Django
Validação de Schema	⭐⭐ Runtime	⭐⭐⭐⭐⭐ Compile-time	SQLx

Relacionamentos e JOINs

# Automático mas implícito
produtos = Produto.objects.select_related('categoria', 'fornecedor')

# Você não vê qual tipo de JOIN está rolando
# É INNER? É LEFT? Django decide por você

// Explícito - você controla cada JOIN
let produtos = sqlx::query!(
    r#"
    SELECT
        p.id, p.nome, p.preco, p.estoque,
        c.nome as "categoria_nome!",
        f.nome as "fornecedor_nome?"
    FROM produtos p
    INNER JOIN categorias c ON p.categoria_id = c.id
    LEFT JOIN fornecedores f ON p.fornecedor_id = f.id
    WHERE p.preco > $1
    ORDER BY p.preco DESC
    "#,
    100.0
)
.fetch_all(pool)
.await?;

Análise: Django é mais rápido de escrever. Mas SQLx deixa cristalino o que está acontecendo. Você vê que categoria é INNER (obrigatório) e fornecedor é LEFT (opcional). O ! e ? na query do SQLx indicam tipos não-nuláveis e nuláveis, respectivamente.

Agregações e Subqueries

Django:

# Fica confuso rápido
from django.db.models import Count, Sum, F, Q, OuterRef, Subquery

vendas_por_categoria = Categoria.objects.annotate(
    total_produtos=Count('produto', distinct=True),
    produtos_em_estoque=Count(
        'produto',
        filter=Q(produto__estoque__gt=0)
    ),
    receita_potencial=Sum(
        F('produto__preco') * F('produto__estoque'),
        filter=Q(produto__estoque__gt=0)
    )
).filter(
    receita_potencial__gt=50000
).order_by('-receita_potencial')

Rust com SQLx:

// SQL puro - sem surpresas
let vendas = sqlx::query!(
    r#"
    SELECT
        c.id,
        c.nome,
        COUNT(DISTINCT p.id) as "total_produtos!",
        COUNT(p.id) FILTER (WHERE p.estoque > 0) as "produtos_em_estoque!",
        COALESCE(SUM(p.preco * p.estoque) FILTER (WHERE p.estoque > 0), 0) as "receita_potencial!"
    FROM categorias c
    LEFT JOIN produtos p ON c.id = p.categoria_id
    GROUP BY c.id, c.nome
    HAVING COALESCE(SUM(p.preco * p.estoque) FILTER (WHERE p.estoque > 0), 0) > $1
    ORDER BY receita_potencial DESC
    "#,
    50000.0
)
.fetch_all(pool)
.await?;

Análise: Para queries complexas, SQL puro é infinitamente mais legível. Você não precisa decorar a sintaxe do Django ORM nem adivinhar qual SQL será gerado. E quando roda EXPLAIN ANALYZE, você vê exatamente a query que escreveu.

Transactions

Django:

from django.db import transaction

@transaction.atomic
def transferir_estoque(origem_id, destino_id, quantidade):
    # select_for_update = lock pessimista
    origem = Estoque.objects.select_for_update().get(id=origem_id)
    destino = Estoque.objects.select_for_update().get(id=destino_id)

    if origem.quantidade < quantidade:
        raise ValueError("Estoque insuficiente")

    origem.quantidade -= quantidade
    destino.quantidade += quantidade

    origem.save()
    destino.save()
    # Se qualquer coisa explodir, rollback automático

SQLx:

async fn transferir_estoque(
    pool: &PgPool,
    origem_id: i32,
    destino_id: i32,
    quantidade: i32,
) -> Result<(), sqlx::Error> {
    let mut tx = pool.begin().await?;

    // SELECT FOR UPDATE explícito
    let origem = sqlx::query!(
        "SELECT quantidade FROM estoque WHERE id = $1 FOR UPDATE",
        origem_id
    )
    .fetch_one(&mut *tx)
    .await?;

    if origem.quantidade < quantidade {
        return Err(sqlx::Error::RowNotFound); // Rollback implícito
    }

    sqlx::query!(
        "UPDATE estoque SET quantidade = quantidade - $1 WHERE id = $2",
        quantidade, origem_id
    )
    .execute(&mut *tx)
    .await?;

    sqlx::query!(
        "UPDATE estoque SET quantidade = quantidade + $1 WHERE id = $2",
        quantidade, destino_id
    )
    .execute(&mut *tx)
    .await?;

    tx.commit().await?;
    Ok(())
}

Análise: SQLx é mais verboso, mas você controla cada passo da transação. O SELECT FOR UPDATE está explícito. O commit é manual. Se você retornar Err, o rollback é automático. Zero mágica, controle total.

O Que SQLx Me Ensinou Sobre Bancos de Dados

Essa é a parte que eu não esperava: usar SQLx me tornou um desenvolvedor melhor, inclusive quando volto para Django.

1. Índices Importam (DE VERDADE)
No Django, você adiciona db_index=True e esquece. No SQLx, quando você escreve WHERE preco > 100 ORDER BY criado_em DESC, você pensa: "Pera, eu tenho um índice em preco? E em criado_em? Devo criar um índice composto?"

Comecei a rodar EXPLAIN ANALYZE em tudo. Descobri que metade dos índices que criava no Django eram inúteis, e faltavam índices críticos em queries reais.

2. JOINs Têm Custo Diferente
INNER JOIN é rápido quando há match. LEFT JOIN traz tudo da tabela esquerda mesmo sem match - mais lento e mais dados. RIGHT JOIN quase ninguém usa (e provavelmente você também não deveria).

No Django, select_related esconde essas decisões. No SQLx, você escolhe o JOIN, e isso te força a pensar na semântica dos dados.

3. Connection Pooling Não É Mágico
Django gerencia o pool automaticamente. Você nem pensa nisso. No SQLx:

let pool = PgPoolOptions::new()
    .max_connections(20)
    .min_connections(5)
    .acquire_timeout(Duration::from_secs(3))
    .connect(&database_url)
    .await?;

Você configura explicitamente quantas conexões, timeouts, behavior de retry. E quando dá erro de "too many connections", você sabe exatamente por quê.

4. Tipos do Banco vs Tipos da Linguagem
Django abstrai: DecimalField vira Decimal em Python. No SQLx, você mapeia explicitamente:

use rust_decimal::Decimal;  // Para NUMERIC/DECIMAL do PostgreSQL
use chrono::{DateTime, Utc};  // Para TIMESTAMP WITH TIME ZONE
use uuid::Uuid;  // Para UUID

#[derive(FromRow)]
struct Produto {
    id: Uuid,
    preco: Decimal,  // Não é f64! Precisão financeira!
    criado_em: DateTime<Utc>,
}

Você aprende que f64 é péssimo para dinheiro (floating point errors). Você entende que timestamps com timezone são diferentes de timestamps ingênuos. Django abstrai isso; SQLx te educa.

5. Prepared Statements são seus amigos
SQLx usa prepared statements por padrão:

sqlx::query!("SELECT * FROM produtos WHERE id = $1", produto_id)

Esse $1 não é interpolação de string. É um placeholder. O PostgreSQL prepara a query uma vez, cacheia o plano de execução, e reutiliza. É mais rápido e previne SQL injection automaticamente.

Django também faz isso, mas você nunca vê. Em SQLx, é impossível não usar prepared statements (a menos que você use .query() com raw SQL, mas aí você perde compile-time checking).

Quando Usar Cada Um?

Quando Usar Cada Um?
Aqui está a verdade: eu não "abandonei" o Django. Uso as duas ferramentas, para coisas diferentes.

Use Django ORM quando:

✅ Você precisa de um MVP/protótipo RÁPIDO - Nada bate Django para validar uma ideia em 2 dias

✅ Seu time é predominantemente Python - Curva de aprendizado de Rust é íngreme; às vezes não vale a pena

✅ As queries são simples - CRUD básico, filtros simples, relacionamentos diretos? Django é imbatível

✅ O Django Admin é requisito - Um backoffice completo de graça é difícil de superar

✅ Performance não é gargalo - Se o banco responde em 50ms e isso é OK para seu SLA, otimização prematura é raiz de todo mal

✅ Você quer migrations automáticas - makemigrations é espetacular; em Rust você usa ferramentas como sqlx-cli migrate ou refinery, mas é mais manual

Use SQLx quando:

✅ Performance e latência são críticas - APIs públicas de alta carga, microserviços que processam milhões de requests

✅ Você tem queries SQL complexas - CTEs, window functions, LATERAL joins - SQL puro é mais legível

✅ Type safety em compile-time é importante - Zero erros de SQL em produção vale ouro

✅ Você quer controle total - Quando você precisa otimizar cada byte e cada milissegundo

✅ Seu time já sabe SQL bem - Se seu time é forte em SQL, SQLx é produtivo rapidamente

✅ Microserviços de alta performance - Serviços stateless, containerizados, que precisam escalar horizontalmente com eficiência

Use os Dois quando:
✅ Sistema híbrido - Django para backoffice/admin, Rust+SQLx para APIs públicas de alta carga

✅ Migração gradual - Comece com Django, identifique gargalos, reescreva apenas esses endpoints em Rust

✅ Equipe mista - Devs Python no backoffice, devs Rust em serviços críticos

Lições da Jornada

Depois de meses nessa transição, aqui estão as lições que carrego:

1. Abstrações São Trade-offs

Django te dá produtividade; SQLx te dá controle. Não existe almoço grátis. Escolha conscientemente qual trade-off seu projeto precisa.

2. Saber SQL de Verdade Importa

SQLx me forçou a ser muito melhor em SQL. E isso é transferível para qualquer stack. Hoje, quando volto para o Django, escrevo queries do ORM muito mais eficientes porque sei o SQL que vai ser gerado.

3. Type Safety É Viciante

Depois que você vê query errors em compile-time, é muito difícil voltar para descobrir em produção que você typo categria em vez de categoria.

4. Curva de Aprendizado Vale a Pena

Os primeiros dias foram duros. Muito. Mas depois da curva, você codifica mais rápido e com mais confiança. Zero medo de refatorar queries, porque o compilador te protege.

5. Django Não É "Ruim"

Sério. O Django é uma ferramenta incrível para o que foi projetado. Rust+SQLx é para cenários diferentes. Use a ferramenta certa para o problema certo.

Conclusão

Desaprender a confiar em mágica foi doloroso. Teve dias que eu pensei "cara, por que não deixo o Django fazer isso automaticamente?". Mas hoje, olhando para trás, valeu cada minuto de frustração.

Não é que SQLx seja "melhor" que Django ORM. É que eles resolvem problemas diferentes. O Django maximiza produtividade para 80% dos casos. SQLx maximiza performance e controle para os 20% críticos.

No fim das contas, eu não abandonei o Django - eu só aprendi quando não usar ele. E isso, ironicamente, me tornou um desenvolvedor Django melhor também. Hoje, quando vejo um select_related, sei exatamente qual JOIN está rolando. Quando vejo um .annotate(), sei qual SQL será gerado. Quando vejo N+1 queries, identifico na hora.

A magia ainda está lá. Eu só entendo os truques agora.

E você sabe o que descobri? Não precisa escolher um lado. Use o Django para prototipar rápido. Use SQLx para otimizar gargalos. Use os dois no mesmo sistema. A melhor stack é a que resolve o problema do jeito mais eficiente, não a que te dá mais pontos de dogmatismo no Twitter.

Se você está confortável demais com seu ORM, talvez seja hora de se desconfortar um pouco. Escreva SQL na mão por algumas semanas. Veja o que você aprende. Não precisa migrar tudo - mas experimente.

Você pode se surpreender com o que descobre quando a magia desaparece.

Quer Mergulhar Fundo no Rust e SQLx?

Se este artigo despertou sua curiosidade sobre como Rust e SQLx funcionam por baixo dos panos, ou se você quer dominar essa transição sem passar pelos mesmos perrengues que eu passei, temos algo especial para você.

"Desbravando Rust" é o guia definitivo para desenvolvedores backend que querem ir além das abstrações e realmente entender como bancos de dados, performance e type safety funcionam em sistemas modernos.

O Que Você Vai Aprender:

SQLx do zero: Desde queries simples até transactions complexas e streaming.

Async/Await em Rust: Como Tokio funciona e por que é tão rápido comparado ao asyncio do Python.

Type Safety na prática: Compile-time checking que salva seu deploy às 3h da manhã.

Migrations e Schema Management: Ferramentas do ecossistema como sqlx-cli e como estruturar projetos reais.

Projetos completos: Construa APIs de produção com Axum + SQLx + PostgreSQL, com testes, observabilidade e deploy.

[pt-BR] Cargo contra rapa

Jose Luis da Cruz Junior — Tue, 28 Jul 2026 11:00:00 +0000

Por @zejuniortdr em Dez 03, 2025

Se você vem de linguagens como JavaScript, Python ou PHP, provavelmente já passou pela "fadiga de configuração". Você quer começar um projeto novo e a primeira hora é gasta decidindo qual gerenciador de pacotes usar, configurando o linter, o formatador, o framework de testes e o bundler.

E se eu te dissesse que no Rust, essa decisão já foi tomada por você, e ela é incrivelmente boa?

Apresento o Cargo: o gerenciador de pacotes, sistema de build, executor de testes, gerador de documentação e melhor amigo do desenvolvedor Rust, com uma prévia do que encontrará no livro que pode ser adquirido no link no final deste post.

O Caos do Tooling Moderno

Para entender o valor do Cargo, precisamos olhar para o estado atual de outras stacks populares. Não me entenda mal, essas linguagens são fantásticas, mas o tooling... bem, é complicado.

O Ecossistema JavaScript/TypeScript

Bem-vindo ao paradoxo da escolha:

Gerenciador de Pacotes: npm? yarn? pnpm? bun?
Build/Bundle: Webpack? Rollup? Vite? Esbuild? Turbopack?
Testes: Jest? Mocha? Vitest? Ava?
Linting/Formatting: ESLint? Prettier? Biome? Standard?

Configurar um projeto TypeScript moderno do zero é quase um rito de passagem. Você precisa de um package.json, tsconfig.json, .eslintrc, .prettierrc, jest.config.js... e torcer para as versões conversarem entre si.

O Ecossistema Python

Python é famoso por ser fácil de ler, mas difícil de gerenciar:

Gerenciamento de Dependências: pip puro? poetry? pipenv? O novo e promissor uv?
Ambientes Virtuais: venv? virtualenv? conda?
Formatação/Linting: black? flake8? pylint? ruff (escrito em Rust, diga-se de passagem)?

O meme "Python environment hell" existe por um motivo.

O Ecossistema PHP

O PHP evoluiu muito. O Composer é uma obra de arte e salvou a linguagem. Mas ele foca estritamente em dependências.
Para um workflow completo, você ainda precisa costurar:

Testes: PHPUnit ou Pest?
Análise Estática: PHPStan ou Psalm?
Formatação: PHP-CS-Fixer ou Pint?

O Jeito Cargo de Ser

Rust adotou uma abordagem diferente: Baterias Inclusas. O Cargo não é apenas um instalador de bibliotecas; ele é um orquestrador de todo o ciclo de vida do desenvolvimento.

Quando você instala o Rust, o Cargo vem junto. E com ele, você tem uma ferramenta padronizada para tudo.

1. Criando Projetos (`cargo new`)

Sem perguntas complexas, sem boilerplate excessivo.

cargo new meu-projeto

Isso cria a estrutura de pastas, inicializa o git e cria o Cargo.toml (o arquivo de configuração). Pronto.

2. Gerenciando Dependências

Quer adicionar uma lib?

cargo add serde --features derive

O Cargo baixa, compila (incluindo dependências das dependências) e garante que tudo funciona. O resolver de versões do Cargo é extremamente robusto e respeita o Semantic Versioning rigorosamente.

3. Build e Execução (`cargo run`)

cargo run

Esse comando compila seu código, linka as bibliotecas e executa o binário. Se você mudar uma linha, ele recompila incrementalmente apenas o necessário.

4. Testes Integrados (`cargo test`)

Não precisa instalar nada. O Rust tem suporte a testes na própria linguagem.

#[test]
fn it_works() {
    assert_eq!(2 + 2, 4);
}

Rodou cargo test, ele encontra todos os testes (unitários, integração e até doc-tests), compila e executa em paralelo. Simples assim.

5. Formatação Padrão (`cargo fmt`)

Chega de brigas em Code Review sobre onde colocar a chave ou se usa aspas simples ou duplas.
O rustfmt é o padrão oficial. Todo código Rust parece ter sido escrito pela mesma pessoa.

cargo fmt

6. O Professor Particular (`cargo clippy`)

O Clippy é mais que um linter; é um mentor. Ele não só aponta erros, mas sugere formas mais idiomáticas ("Rustacean") de escrever seu código.

cargo clippy

Ele vai te dizer: "Ei, você está usando um loop for aqui, mas um iterator seria mais rápido e legível. Tente assim..."

7. Correções Automáticas (`cargo fix`)

Complementando o Clippy, o cargo fix pode aplicar automaticamente muitas das sugestões e correções que o Clippy (e o próprio compilador) identificam. Isso transforma warnings em ações concretas, economizando tempo e garantindo que seu código esteja sempre em conformidade com as melhores práticas da linguagem.

cargo fix --edition

8. Documentação Automática (`cargo doc`)

cargo doc --open

Esse comando gera um site estático com a documentação de todas as suas dependências e do seu próprio código, offline, navegável e padronizado. É mágico.

Por que isso importa?

A padronização do Cargo elimina a fadiga de decisão.
Em vez de gastar energia configurando ferramentas, você gasta energia resolvendo o problema do seu negócio.

Se você entrar em um projeto Rust open-source hoje, seja ele pequeno ou gigante (como o kernel do Linux ou o próprio compilador do Rust), você sabe exatamente como rodar, testar e documentar: cargo run, cargo test, cargo doc.

Essa consistência cria uma comunidade mais coesa e produtiva. Enquanto outras stacks tentam reinventar a roda a cada 6 meses com uma nova ferramenta de build "revolucionária", a comunidade Rust continua aprimorando o Cargo, que já é excelente há anos.

Conclusão

O Cargo não é perfeito, mas é o mais próximo que temos de uma "experiência de desenvolvedor ideal" em linguagens de sistema. Ele prova que uma linguagem difícil de aprender não precisa ter um tooling difícil de usar. Pelo contrário: o tooling do Rust é tão bom que muitas vezes ele te ensina a linguagem.

Se você está cansado de configurar Webpack, brigar com ambientes virtuais Python ou configurar o PHPUnit xml, dê uma chance ao Rust. O Cargo vai te mal acostumar.

Benchmarks

Recurso / Ferramenta	Cargo (Rust)	npm/Yarn/pnpm (JS)	Composer (PHP)	Pip (Python)	Pipenv (Python)	uv (Python)
Gerenciador de Pacotes	✅	✅	✅	✅	✅	✅
Sistema de Build	✅	❌²	❌	❌	❌	❌
Executor de Testes	✅	❌²	❌²	❌²	❌²	❌²
Gerador de Documentação	✅	❌²	❌	❌	❌	❌
Linter/Formatador	✅	❌²	❌²	❌²	❌²	❌²
Ambientes Virtuais	❌¹	❌¹	❌¹	❌¹	✅	✅
Resolução de Dependências	✅✅³	✅	✅	✅	✅	✅✅³
Linguagem Principal	Rust	JavaScript	PHP	Python	Python	Python

¹: Não é um conceito diretamente comparável ou necessário para a linguagem da mesma forma. No JS, node_modules local serve a um propósito similar.
²: Ferramenta externa usualmente orquestrada por scripts ou outras ferramentas.
³: Um duplo ✅ indica um sistema de resolução de dependências mais robusto e determinístico, frequentemente com um algoritmo de satisfação de booleanos (SAT solver) que garante que todas as dependências sejam resolvidas para uma única versão compatível, mesmo em grafos complexos.

Quer experimentar esse poder na prática?

No livro "Desbravando Rust", dedicamos capítulos inteiros para explorar o ecossistema do Cargo, ensinando não só a sintaxe da linguagem, mas como usar essas ferramentas para criar software robusto, testado e documentado desde o primeiro dia.

Garanta seu exemplar e pare de brigar com configurações!

[pt-BR] Pandas vs Polars: Benchmark com 3 Milhões de Registros

Jose Luis da Cruz Junior — Tue, 21 Jul 2026 11:00:00 +0000

Por @zejuniortdr em Nov 21, 2025

Recentemente caiu na minha timeline um vídeo do Lewis apresentando um pacote do python que ele classificou como incrível:

O pacote em questão é o Polars. Como o próprio site oficial diz:

Polars is an open-source library for data manipulation, known for being one of the fastest data processing solutions on a single machine. It features a well-structured, typed API that is both expressive and easy to use.

E como ele consegue ser tão incrível e apresentar resultados tão absurdos? É escrito em Rust 🦀.

Este artigo nasceu da inspiração sobre o tema depois de uma aula de Pandas com o Rafael Dias e da provocação da Amanda Ozava que lembrou bem quando compartilhei com ela o vídeo acima.

Dado ambos com mais experiência que eu no assunto, achei por bem citá-los aqui e pedir para que fizessem uma revisão no material que compartilharei abaixo.

Meu primeiro contato com o Pandas foi em um Nano Degree da Udacity:
Programming for Data Science with Python e de lá para cá não tive muita oportunidade de usá-lo. O material abaixo é fruto de uma pesquisa ao longo de alguns dias (desde a talk do Rafa), obviamente com algum viés para o bench entre os dois pacotes.

O que são DataFrames?

Se você já trabalhou com planilhas do Excel ou Google Sheets, você já conhece o conceito de DataFrame sem saber. Um DataFrame é basicamente uma tabela de dados com:

Linhas: cada linha representa um registro (como uma linha na planilha)
Colunas: cada coluna representa um atributo ou campo (como uma coluna na planilha)
Tipos de dados: cada coluna tem um tipo específico (números, texto, datas, etc.)

A diferença é que DataFrames são projetados para:

Processar milhões de linhas de forma eficiente
Realizar operações complexas em poucos comandos
Integrar-se com ferramentas de análise de dados e machine learning

Pandas tem sido a biblioteca padrão para isso em Python desde 2008. Polars é o novo competidor que promete fazer tudo isso, só que muito mais rápido.

Semelhanças: O Território Comum

Antes de falarmos das diferenças, é importante entender que ambas as bibliotecas compartilham os mesmos conceitos fundamentais:

Estruturas de Dados

DataFrames: Estruturas tabulares bidimensionais com linhas e colunas
Series: Estruturas unidimensionais representando uma única coluna
Operações vetorizadas: Em vez de processar um dado por vez (como um loop), processam lotes inteiros de dados de uma só vez
Suporte a diversos formatos: CSV, Parquet, JSON, Excel e outros

Operações Comuns
As operações fundamentais são suportadas por ambas:

Filtros e seleções: Escolher linhas e colunas específicas
Agregações: Somar, calcular médias, contar elementos, etc.
Joins e merges: Combinar dados de múltiplas tabelas
Transformações: Criar novas colunas baseadas em cálculos
Agrupamentos: Agrupar dados por categorias e aplicar operações

Exemplo Equivalente - Filtro Simples

#Pandas
pythondf_filtrado = df[df['quantidade'] > 5]

# Polars
pythondf_filtrado = df.filter(pl.col('quantidade') > 5)

Ambas fazem a mesma coisa: filtram as linhas onde a coluna 'quantidade' é maior que 5. A sintaxe é um pouco diferente, mas o conceito é idêntico.

Diferenças: Onde Polars se Destaca

Agora vamos ao que realmente interessa: o que torna Polars tão especial? As diferenças vão muito além da sintaxe.

1. Linguagem de Implementação: A Base de Tudo

Aqui está o grande diferencial:

Pandas:

Construído sobre NumPy, que tem seu núcleo escrito em C
Limitado pelo GIL (Global Interpreter Lock) do Python - uma trava que impede que múltiplas threads Python executem ao mesmo tempo
Sofre com overhead (custo adicional) ao lidar com tipos Python, especialmente strings

Polars:

Escrito completamente em Rust 🦀
Performance próxima de C/C++, mas com segurança de memória garantida
Sem limitações do GIL - paralelização nativa e verdadeira
Gerenciamento de memória eficiente e sem overhead.

Impacto visível: Polars é 5-10x mais rápido em operações comuns. Em alguns casos específicos, pode ser até 100x mais rápido.

2. Modelo de Execução: Eager vs Lazy

Esta é uma das diferenças mais importantes e que mais impacta a performance.

Pandas - Eager Execution (Execução Imediata)
Pandas executa cada operação imediatamente, na ordem em que você escreve:

df.assign(nova_col=lambda x: x['a'] * 2)     # Executa agora
  .query('quantidade > 100')                 # Depois executa isso
  .groupby('categoria').mean()               # Por último isso

O problema: ele processa todos os dados primeiro, para depois filtrar. É como preparar um banquete completo para depois descobrir que só 10% dos convidados apareceram.

Polars - Lazy + Eager Execution (Execução Preguiçosa + Imediata)
Polars oferece dois modos:

Modo Eager (padrão): Similar ao Pandas, executa imediatamente
Modo Lazy (recomendado): Constrói um plano de execução e otimiza antes de executar

df.lazy()                                        # Entra em modo lazy
  .with_columns((pl.col('a') * 2).alias('nova_col'))
  .filter(pl.col('quantidade') > 100)            # Ainda não executou nada
  .group_by('categoria').mean()
  .collect()                                     # AGORA executa tudo otimizado

O que Polars faz nos bastidores:

Reordena operações: Aplica filtros ANTES de fazer cálculos pesados
Elimina redundâncias: Remove cálculos que não serão usados
Otimiza memória: Processa apenas o necessário
Paraleliza: Divide o trabalho entre múltiplos núcleos

É como ter um assistente inteligente que reorganiza sua lista de tarefas para fazer tudo mais rápido.

3. Sintaxe e Estilo de Código

Pandas - Flexível Demais

Pandas é muito flexível, o que pode ser bom para iniciantes, mas ruim para manutenção:

# Múltiplas formas de fazer a mesma coisa:
df[df['a'] > 5]
df.query('a > 5')
df.loc[df['a'] > 5]

Para operações complexas, você frequentemente precisa usar .apply() com lambdas (funções anônimas), que são lentas porque processam linha por linha:

# Operação condicional com .mask()
df.assign(a=lambda df_: df_['a'].mask(df_['c'] == 2, df_['b']))

# Apply sequencial (lento!)
df['resultado'] = df.apply(lambda row: complexa_func(row), axis=1)

Polars - Consistente e Expressivo

Polars usa uma API baseada em expressões e contextos. Tudo é mais consistente:

# Operação condicional clara
df.with_columns(
    pl.when(pl.col('c') == 2)
    .then(pl.col('b'))
    .otherwise(pl.col('a'))
    .alias('a')
)

# Operação nativa e paralela (rápida!)
df.with_columns(
    pl.col('valores').map_elements(complexa_func)  # Automaticamente paralelizado
)

A sintaxe de Polars pode parecer mais verbosa no início, mas é:

Mais explícita: Fica claro o que está acontecendo
Mais consistente: Sempre usa o mesmo padrão
Mais rápida: Evita loops implícitos

4. Paralelização e Concorrência

Pandas - Praticamente Single-Threaded

Pandas roda majoritariamente em um único núcleo do seu processador:

# Pandas opera majoritariamente em um único núcleo, exceto por algumas operações vetorizadas que podem usar paralelismo interno do NumPy.
df.groupby('categoria')['valor'].sum()

Por quê? Por causa do GIL (Global Interpreter Lock) do Python. É como ter um carro de 8 cilindros, mas só poder usar 1 de cada vez.

Para ter paralelismo real em Pandas, você precisa de bibliotecas externas como:

Dask: Pandas paralelo para datasets grandes
Modin: Drop-in replacement que paraleliza Pandas
Ray: Framework de computação distribuída

Polars - Paralelização Nativa

Polars usa todos os núcleos disponíveis automaticamente:

# Usa todos os núcleos automaticamente
df.group_by('categoria').agg(pl.col('valor').sum())

Além disso, Polars usa SIMD (Single Instruction, Multiple Data) - uma tecnologia que permite processar múltiplos valores com uma única instrução do processador. É como ter um supermercado com múltiplos caixas, todos trabalhando simultaneamente.

Pandas também usa SIMD em algumas operações via NumPy. Exemplo: operações vetorizadas:

df["price_with_tax"] = df["price"] * 1.12

5. Tipos de Dados e Strictness

Pandas - Loose Typing (Tipagem Flexível)

Pandas faz conversões automáticas de tipos, o que pode parecer conveniente, mas gera bugs silenciosos:

df = pd.DataFrame({'valores': [1, 2, 3, 4, 5]})
print(df['valores'].dtype)  # int64

df.loc[5] = [None]  # Adiciona um valor None
print(df['valores'].dtype)  # float64 (converteu TODA a coluna!)

O que aconteceu? Ao adicionar um None (que representa ausência de valor), Pandas converteu toda a coluna de inteiros para floats, porque inteiros não podem representar valores ausentes nativamente.

Polars - Strict Typing (Tipagem Estrita)

Polars é rigoroso com tipos e te força a ser explícito:

df = pl.DataFrame({'valores': [1, 2, 3, 4, 5]})

# Isso dá erro!
df.extend(pl.DataFrame({'valores': [None]}))
# Error: type mismatch

# Forma correta - seja explícito
df.extend(pl.DataFrame({'valores': [pl.Null]}))  # OK com tipo correto

Por que isso é bom? Porque erros explícitos são melhores que bugs silenciosos. Você descobre o problema imediatamente, não depois de horas de depuração.

6. Uso de Memória

Pandas - Guloso com RAM

Pandas requer 5-10x o tamanho do dataset em memória RAM:

Copia dados frequentemente entre operações
Não tem suporte nativo para datasets maiores que a memória
Precisa carregar tudo na RAM de uma vez

Se você tem um arquivo CSV de 1GB, pode precisar de 10GB de RAM para processá-lo com Pandas.

Polars - Eficiente e com Streaming

Polars requer apenas 2-4x o tamanho do dataset:

Usa zero-copy operations sempre que possível (reutiliza dados sem copiar)
Suporte nativo a streaming para datasets maiores que a RAM
Processa dados em chunks (pedaços) quando necessário

# Processar arquivo maior que a memória disponível
pl.scan_csv('arquivo_gigante.csv')           # Não carrega tudo
  .filter(pl.col('data') > '2024-01-01')     # Filtra durante a leitura
  .group_by('categoria')
  .agg(pl.col('valor').sum())
  .sink_csv('resultado.csv')                 # Streaming! Não sobrecarrega RAM

Com Polars, você pode processar arquivos de 50GB em uma máquina com 8GB de RAM.

7. Operações Complexas: Apply vs Expressões Nativas

Pandas - Dependente de `.apply()`

Para operações complexas, Pandas frequentemente te força a usar .apply(), que é lento:

# Loop implícito - processa linha por linha
df['novo'] = df.apply(
    lambda row: row['a'] * row['b'] if row['c'] > 10 else 0,
    axis=1
)

O .apply() é lento porque:

Itera linha por linha (perde vetorização)
Tem overhead do Python para cada linha
Não pode ser paralelizado facilmente

Polars - Métodos Nativos para Tudo

Polars tem métodos nativos (escritos em Rust) para praticamente tudo:

# Operação vetorizada e paralela
df.with_columns(
    pl.when(pl.col('c') > 10)
    .then(pl.col('a') * pl.col('b'))
    .otherwise(0)
    .alias('novo')
)

Por ser nativo em Rust:

Vetorizado: Processa múltiplas linhas de uma vez
Paralelizado: Usa múltiplos núcleos automaticamente
Zero overhead: Sem custo adicional do Python

8. Ecossistema e Maturidade

Pandas - Maduro e Integrado

Vantagens:

Maturidade: Desde 2008, extremamente estável
Ecossistema rico: Integração profunda com scikit-learn, matplotlib, seaborn, statsmodels
Documentação extensa: Milhares de tutoriais e respostas no Stack Overflow
Comunidade gigante: Fácil encontrar ajuda

Quando usar: Se você precisa de integração imediata com ferramentas de machine learning.

Polars - Novo mas Crescendo Rápido

Situação atual:

Maturidade: Desde 2020, mas já muito estável
Crescimento acelerado: Comunidade crescendo exponencialmente
Interoperabilidade: Fácil converter para Pandas quando necessário

# Usar Polars para processamento pesado
df_polars = pl.DataFrame({'a': [1, 2, 3, 4, 5]})

# Converter para Pandas quando precisar de scikit-learn
df_pandas = df_polars.to_pandas()
model.fit(df_pandas)

# E vice-versa
df_polars_novamente = pl.from_pandas(df_pandas)

Tendência: Cada vez mais bibliotecas estão adicionando suporte direto a Polars.

Quando Usar Cada Uma?

Use Pandas quando:

Datasets pequenos/médios (< 1GB): Se cabe confortavelmente na memória, Pandas funciona bem;
Prototipagem rápida e exploração: Sintaxe mais familiar para quem está começando e ótimo para análise exploratória em Jupyter notebooks;
Integração profunda com ML: scikit-learn, statsmodels, TensorFlow integram nativamente. Também não quer o overhead de converter dados;
Time já familiarizado: Equipe já domina Pandas e o custo de mudança não se justifica (ainda);

Use Polars quando:

Performance é crítica: Processamento precisa ser rápido e economia de tempo/recursos tem valor significativo;
Datasets grandes (> 1GB): Arquivos de vários gigabytes e precisa processar milhões/bilhões de linhas;
Operações de agregação/groupby pesadas: Para agrupamentos complexos com múltiplas agregações, o Polars pode ser 10-50x mais rápido;
Dados maiores que memória: Suporte nativo a streaming e consegue processar arquivos de 50GB com 8GB de RAM;
Código em produção que precisa escalar: Aplicações que rodam frequentemente, custos de infraestrutura importam e/ou desempenho impacta experiência do usuário;

Exemplos Práticos: Comparando as Três Abordagens

Toda essa parte teórica com exemplos simples foram para criar uma fundação mínima de conhecimento para quem nunca viu algum destes pacotes e conseguirmos seguir na parte que realmente importa deste artigo.

Não é que eu duvide do Lewis, mas por se tratar de números tão absurdos, resolvi testar reproduzindo o mesmo cenário que ele criou: processar três milhões de linhas de um arquivo CSV com ambas e para cereja do bolo, resolvi fazer um teste apelativo para ver se traria muita diferença. Também inclui neste benchmark processar o mesmo arquivo com Rust + Polars.

Para gerar esse arquivo inicial, utilizei o seguinte script em python:

import csv
import random
from datetime import datetime, timedelta
from pathlib import Path

def generate_sales_data(num_records=3_000_000, output_file="data/sales_data.csv"):
    """Gera dados sintéticos de vendas"""
    Path("data").mkdir(exist_ok=True)

    products = ["Laptop", "Mouse", "Keyboard", "Monitor", "Headset",
                "Webcam", "SSD", "RAM", "GPU", "CPU"]
    categories = ["Electronics", "Accessories", "Components"]
    regions = ["North", "South", "East", "West", "Central"]

    start_date = datetime(2023, 1, 1)

    print(f"Gerando {num_records:,} registros...")

    with open(output_file, 'w', newline='', encoding='utf-8') as f:
        writer = csv.writer(f)
        writer.writerow([
            'id', 'date', 'product', 'category', 'region',
            'quantity', 'price', 'discount', 'customer_id'
        ])

        for i in range(num_records):
            date = start_date + timedelta(days=random.randint(0, 730))
            product = random.choice(products)
            category = random.choice(categories)
            region = random.choice(regions)
            quantity = random.randint(1, 20)
            price = round(random.uniform(10, 2000), 2)
            discount = round(random.uniform(0, 0.3), 2)
            customer_id = random.randint(1, 50000)

            writer.writerow([
                i, date.strftime('%Y-%m-%d'), product, category,
                region, quantity, price, discount, customer_id
            ])

            if (i + 1) % 500_000 == 0:
                print(f"  {i + 1:,} registros gerados...")

    print(f"✓ Arquivo gerado: {output_file}")

if __name__ == "__main__":
    generate_sales_data()

Com as seguintes dependências:

pandas = "==2.3.3"
polars-lts-cpu = "==1.33.1"
psutil = "==7.1.3"

Exemplo 1: Python + Pandas

Para o bench para este cenário, foi utilizado o seguinte script:

import pandas as pd
import time
import psutil
import os
from pathlib import Path

def get_memory_usage():
    """Retorna uso de memória em MB"""
    process = psutil.Process(os.getpid())
    return process.memory_info().rss / (1024 * 1024)

def benchmark_pandas():
    Path("results").mkdir(exist_ok=True)

    metrics = {
        'library': 'Pandas',
        'operations': {},
        'total_time': 0,
        'peak_memory_mb': 0
    }

    initial_memory = get_memory_usage()
    start_total = time.time()

    # 1. LEITURA
    print("1. Lendo CSV...")
    start = time.time()
    df = pd.read_csv('data/sales_data.csv')
    read_time = time.time() - start
    metrics['operations']['read_csv'] = read_time
    print(f"   Tempo: {read_time:.2f}s | Memória: {get_memory_usage():.2f} MB")

    # 2. FILTROS
    print("2. Aplicando filtros...")
    start = time.time()
    filtered = df[(df['quantity'] > 5) & (df['price'] > 100)]
    filter_time = time.time() - start
    metrics['operations']['filter'] = filter_time
    print(f"   Tempo: {filter_time:.2f}s | Registros: {len(filtered):,}")

    # 3. AGREGAÇÕES
    print("3. Agregações (groupby)...")
    start = time.time()
    agg_result = df.groupby(['region', 'category']).agg({
        'quantity': 'sum',
        'price': 'mean',
        'id': 'count'
    }).reset_index()
    agg_time = time.time() - start
    metrics['operations']['aggregation'] = agg_time
    print(f"   Tempo: {agg_time:.2f}s | Grupos: {len(agg_result):,}")

    # 4. TRANSFORMAÇÕES
    print("4. Transformações de colunas...")
    start = time.time()
    df['total_price'] = df['quantity'] * df['price'] * (1 - df['discount'])
    df['year'] = pd.to_datetime(df['date']).dt.year
    transform_time = time.time() - start
    metrics['operations']['transform'] = transform_time
    print(f"   Tempo: {transform_time:.2f}s")

    # 5. JOINS
    print("5. Join de dataframes...")
    start = time.time()
    summary = df.groupby('customer_id')['total_price'].sum().reset_index()
    summary.columns = ['customer_id', 'total_spent']
    joined = df.merge(summary, on='customer_id', how='left')
    join_time = time.time() - start
    metrics['operations']['join'] = join_time
    print(f"   Tempo: {join_time:.2f}s")

    # 6. ESCRITA
    print("6. Escrevendo resultado...")
    start = time.time()
    top_customers = joined.groupby('customer_id')['total_spent'].first()\
        .sort_values(ascending=False).head(1000)
    top_customers.to_csv('results/pandas_top_customers.csv')
    write_time = time.time() - start
    metrics['operations']['write_csv'] = write_time
    print(f"   Tempo: {write_time:.2f}s")

    # MÉTRICAS FINAIS
    total_time = time.time() - start_total
    peak_memory = get_memory_usage()

    metrics['total_time'] = total_time
    metrics['peak_memory_mb'] = peak_memory - initial_memory

    print(f"\n{'='*50}")
    print(f"PANDAS - Tempo total: {total_time:.2f}s")
    print(f"PANDAS - Memória pico: {peak_memory - initial_memory:.2f} MB")
    print(f"{'='*50}\n")

    # Salvar métricas
    import json
    with open('results/pandas_metrics.json', 'w') as f:
        json.dump(metrics, f, indent=2)

    return metrics

if __name__ == "__main__":
    benchmark_pandas()

Exemplo 2: Python + Polars

Eis o script, também em python processa o mesmo arquivo do exemplo anterior, só que agora com o Polars:

import polars as pl
import time
import psutil
import os
from pathlib import Path

def get_memory_usage():
    process = psutil.Process(os.getpid())
    return process.memory_info().rss / (1024 * 1024)

def benchmark_polars_python():
    Path("results").mkdir(exist_ok=True)

    metrics = {
        'library': 'Polars (Python)',
        'operations': {},
        'total_time': 0,
        'peak_memory_mb': 0
    }

    initial_memory = get_memory_usage()
    start_total = time.time()

    # 1. LEITURA (Lazy)
    print("1. Lendo CSV (lazy)...")
    start = time.time()
    df = pl.scan_csv('data/sales_data.csv')
    read_time = time.time() - start
    metrics['operations']['read_csv'] = read_time
    print(f"   Tempo: {read_time:.4f}s (lazy) | Memória: {get_memory_usage():.2f} MB")

    # 2. FILTROS
    print("2. Aplicando filtros...")
    start = time.time()
    filtered = df.filter(
        (pl.col('quantity') > 5) & (pl.col('price') > 100)
    )
    filter_time = time.time() - start
    metrics['operations']['filter'] = filter_time
    print(f"   Tempo: {filter_time:.4f}s (lazy)")

    # 3. AGREGAÇÕES
    print("3. Agregações (groupby)...")
    start = time.time()
    agg_result = df.group_by(['region', 'category']).agg([
        pl.col('quantity').sum().alias('total_quantity'),
        pl.col('price').mean().alias('avg_price'),
        pl.col('id').count().alias('count')
    ])
    agg_time = time.time() - start
    metrics['operations']['aggregation'] = agg_time
    print(f"   Tempo: {agg_time:.4f}s (lazy)")

    # 4. TRANSFORMAÇÕES
    print("4. Transformações de colunas...")
    start = time.time()
    df = df.with_columns([
        (pl.col('quantity') * pl.col('price') * (1 - pl.col('discount')))
            .alias('total_price'),
        pl.col('date').str.strptime(pl.Date, '%Y-%m-%d').dt.year().alias('year')
    ])
    transform_time = time.time() - start
    metrics['operations']['transform'] = transform_time
    print(f"   Tempo: {transform_time:.4f}s (lazy)")

    # 5. JOINS
    print("5. Join de dataframes...")
    start = time.time()
    summary = df.group_by('customer_id').agg(
        pl.col('total_price').sum().alias('total_spent')
    )
    joined = df.join(summary, on='customer_id', how='left')
    join_time = time.time() - start
    metrics['operations']['join'] = join_time
    print(f"   Tempo: {join_time:.4f}s (lazy)")

    # 6. EXECUÇÃO + ESCRITA
    print("6. Executando query e escrevendo resultado...")
    start = time.time()
    top_customers = (joined
        .group_by('customer_id')
        .agg(pl.col('total_spent').first())
        .sort('total_spent', descending=True)
        .head(1000)
        .collect()  # Aqui executa tudo!
    )
    top_customers.write_csv('results/polars_python_top_customers.csv')
    write_time = time.time() - start
    metrics['operations']['write_csv'] = write_time
    print(f"   Tempo: {write_time:.2f}s (execução + escrita)")

    # MÉTRICAS FINAIS
    total_time = time.time() - start_total
    peak_memory = get_memory_usage()

    metrics['total_time'] = total_time
    metrics['peak_memory_mb'] = peak_memory - initial_memory

    print(f"\n{'='*50}")
    print(f"POLARS (Python) - Tempo total: {total_time:.2f}s")
    print(f"POLARS (Python) - Memória pico: {peak_memory - initial_memory:.2f} MB")
    print(f"{'='*50}\n")

    import json
    with open('results/polars_python_metrics.json', 'w') as f:
        json.dump(metrics, f, indent=2)

    return metrics

if __name__ == "__main__":
    benchmark_polars_python()

Exemplo 3: Rust + Polars

E por fim mas não menos importante, o exemplo em Rust com Polars que é praticamente uma F1 nessa corrida de velotrol:

use polars::prelude::*;
use std::time::Instant;
use std::fs;
use sysinfo::System;

fn get_memory_usage() -> f64 {
    let mut sys = System::new_all();
    sys.refresh_memory();
    sys.used_memory() as f64 / (1024.0 * 1024.0)
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    fs::create_dir_all("results")?;

    let initial_memory = get_memory_usage();
    let start_total = Instant::now();

    // 1. LEITURA (Lazy)
    println!("1. Lendo CSV (lazy)...");
    let start = Instant::now();
    let df = LazyCsvReader::new("data/sales_data.csv")
        .with_has_header(true)
        .finish()?;
    let read_time = start.elapsed();
    println!("   Tempo: {:?} (lazy) | Memória: {:.2} MB", read_time, get_memory_usage());

    // 2. FILTROS
    println!("2. Aplicando filtros...");
    let start = Instant::now();
    let _filtered = df.clone().filter(
        col("quantity").gt(lit(5))
            .and(col("price").gt(lit(100.0)))
    );
    let filter_time = start.elapsed();
    println!("   Tempo: {:?} (lazy)", filter_time);

    // 3. AGREGAÇÕES
    println!("3. Agregações (groupby)...");
    let start = Instant::now();
    let _agg_result = df.clone()
        .group_by([col("region"), col("category")])
        .agg([
            col("quantity").sum().alias("total_quantity"),
            col("price").mean().alias("avg_price"),
            col("id").count().alias("count"),
        ]);
    let agg_time = start.elapsed();
    println!("   Tempo: {:?} (lazy)", agg_time);

    // 4. TRANSFORMAÇÕES
    println!("4. Transformações de colunas...");
    let start = Instant::now();
    let df = df.with_columns([
        (col("quantity") * col("price") * (lit(1.0) - col("discount")))
            .alias("total_price"),
    ]);
    let transform_time = start.elapsed();
    println!("   Tempo: {:?} (lazy)", transform_time);

    // 5. JOINS
    println!("5. Join de dataframes...");
    let start = Instant::now();
    let summary = df.clone()
        .group_by([col("customer_id")])
        .agg([col("total_price").sum().alias("total_spent")]);

    let joined = df.join(
        summary,
        [col("customer_id")],
        [col("customer_id")],
        JoinArgs::new(JoinType::Left),
    );
    let join_time = start.elapsed();
    println!("   Tempo: {:?} (lazy)", join_time);

    // 6. EXECUÇÃO + ESCRITA
    println!("6. Executando query e escrevendo resultado...");
    let start = Instant::now();
    let top_customers = joined
        .group_by([col("customer_id")])
        .agg([col("total_spent").first()])
        .sort(
            ["total_spent"],
            SortMultipleOptions::default().with_order_descending(true),
        )
        .limit(1000)
        .collect()?; // Executa aqui!

    let mut file = std::fs::File::create("results/polars_rust_top_customers.csv")?;
    CsvWriter::new(&mut file)
        .include_header(true)
        .finish(&mut top_customers.clone())?;

    let write_time = start.elapsed();
    println!("   Tempo: {:?} (execução + escrita)", write_time);

    // MÉTRICAS FINAIS
    let total_time = start_total.elapsed();
    let peak_memory = get_memory_usage() - initial_memory;

    println!("\n{}", "=".repeat(50));
    println!("POLARS (Rust) - Tempo total: {:.2?}", total_time);
    println!("POLARS (Rust) - Memória pico: {:.2} MB", peak_memory);
    println!("{}\n", "=".repeat(50));

    // Salvar métricas
    let metrics = format!(
        r#"{{
  "library": "Polars (Rust)",
  "total_time": {:.2},
  "peak_memory_mb": {:.2}
}}"#,
        total_time.as_secs_f64(),
        peak_memory
    );

    fs::write("results/polars_rust_metrics.json", metrics)?;

    Ok(())
}

Resultados

Cada um dos exemplos acima foram executados na mesma máquina do post Performance na prática: Um exemplo de real onde o Axum supera o FastAPI, e criei um script em python para analisar as saídas geradas na pasta results/:

import json
import pandas as pd
from pathlib import Path

def compare_results():
    results_dir = Path("results")

    # Carregar métricas
    with open(results_dir / "pandas_metrics.json") as f:
        pandas_data = json.load(f)

    with open(results_dir / "polars_python_metrics.json") as f:
        polars_py_data = json.load(f)

    with open(results_dir / "polars_rust_metrics.json") as f:
        polars_rust_data = json.load(f)

    # Criar tabela comparativa
    comparison = pd.DataFrame({
        'Biblioteca': [
            pandas_data['library'],
            polars_py_data['library'],
            polars_rust_data['library']
        ],
        'Tempo Total (s)': [
            f"{pandas_data['total_time']:.2f}",
            f"{polars_py_data['total_time']:.2f}",
            f"{polars_rust_data['total_time']:.2f}"
        ],
        'Memória Pico (MB)': [
            f"{pandas_data['peak_memory_mb']:.2f}",
            f"{polars_py_data['peak_memory_mb']:.2f}",
            f"{polars_rust_data['peak_memory_mb']:.2f}"
        ]
    })

    print("\n" + "="*60)
    print("COMPARAÇÃO FINAL: Pandas vs Polars (Python) vs Polars (Rust)")
    print("="*60)
    print(comparison.to_string(index=False))
    print("="*60)

    # Calcular speedup
    pandas_time = pandas_data['total_time']
    polars_py_time = polars_py_data['total_time']
    polars_rust_time = polars_rust_data['total_time']

    print(f"\nSPEEDUP:")
    print(f"  Polars (Python) vs Pandas: {pandas_time/polars_py_time:.2f}x mais rápido")
    print(f"  Polars (Rust) vs Pandas: {pandas_time/polars_rust_time:.2f}x mais rápido")
    print(f"  Polars (Rust) vs Polars (Python): {polars_py_time/polars_rust_time:.2f}x mais rápido")

    print(f"\nREDUÇÃO DE MEMÓRIA:")
    pandas_mem = pandas_data['peak_memory_mb']
    polars_py_mem = polars_py_data['peak_memory_mb']
    polars_rust_mem = polars_rust_data['peak_memory_mb']

    print(f"  Polars (Python) vs Pandas: {((pandas_mem-polars_py_mem)/pandas_mem*100):.1f}% menos memória")
    print(f"  Polars (Rust) vs Pandas: {((pandas_mem-polars_rust_mem)/pandas_mem*100):.1f}% menos memória")
    print()

if __name__ == "__main__":
    compare_results()

Eis os números:

Para facilitar a execução de todos e coletar principalmente os picos de consumo de cpu e e memória de uma forma fácil, utilizei o seguinte Makefile:

bench:
    echo "============================================"
    echo "Python + Pandas"
    python scripts/2_benchmark_pandas.py
    echo "============================================"
    sleep 15

    echo "============================================"
    echo "Python + Polars"
    python scripts/2_benchmark_pandas.py
    echo "============================================"
    sleep 15

    echo "============================================"
    echo "Rust + Polars"
    ./target/release/pandas-vs-polars
    echo "============================================"
    sleep 15

    echo "Resultados"
    python scripts/5_compare_results.py

Depois de rodar o primeiro script para gerar o arquivo, simplesmente rodei esse bench, com intervalos de 15s entre cada um para mapear os picos. Os números foram surpreendentes:

➜  make bench
echo "============================================"
============================================
echo "Python + Pandas"
Python + Pandas
python scripts/2_benchmark_pandas.py
1. Lendo CSV...
   Tempo: 2.56s | Memória: 302.78 MB
2. Aplicando filtros...
   Tempo: 0.12s | Registros: 2,148,184
3. Agregações (groupby)...
   Tempo: 0.33s | Grupos: 15
4. Transformações de colunas...
   Tempo: 0.58s
5. Join de dataframes...
   Tempo: 0.37s
6. Escrevendo resultado...
   Tempo: 0.07s

==================================================
PANDAS - Tempo total: 4.05s
PANDAS - Memória pico: 782.25 MB
==================================================

echo "============================================"
============================================
sleep 15
echo "============================================"
============================================
echo "Python + Polars"
Python + Polars
python scripts/2_benchmark_pandas.py
1. Lendo CSV...
   Tempo: 2.49s | Memória: 302.79 MB
2. Aplicando filtros...
   Tempo: 0.12s | Registros: 2,148,184
3. Agregações (groupby)...
   Tempo: 0.35s | Grupos: 15
4. Transformações de colunas...
   Tempo: 0.53s
5. Join de dataframes...
   Tempo: 0.37s
6. Escrevendo resultado...
   Tempo: 0.07s

==================================================
PANDAS - Tempo total: 3.93s
PANDAS - Memória pico: 782.39 MB
==================================================

echo "============================================"
============================================
sleep 15
echo "============================================"
============================================
echo "Rust + Polars"
Rust + Polars
./target/release/pandas-vs-polars
1. Lendo CSV (lazy)...
   Tempo: 23.295µs (lazy) | Memória: 2659.56 MB
2. Aplicando filtros...
   Tempo: 206.271µs (lazy)
3. Agregações (groupby)...
   Tempo: 13.338µs (lazy)
4. Transformações de colunas...
   Tempo: 4.626µs (lazy)
5. Join de dataframes...
   Tempo: 14.751µs (lazy)
6. Executando query e escrevendo resultado...
   Tempo: 618.259553ms (execução + escrita)

==================================================
POLARS (Rust) - Tempo total: 634.52ms
POLARS (Rust) - Memória pico: 312.22 MB
==================================================

echo "============================================"
============================================
sleep 15
echo "Resultados"
Resultados
python scripts/5_compare_results.py

============================================================
COMPARAÇÃO FINAL: Pandas vs Polars (Python) vs Polars (Rust)
============================================================
     Biblioteca Tempo Total (s) Memória Pico (MB)
         Pandas            3.93            782.39
Polars (Python)            0.35            311.11
  Polars (Rust)            0.63            312.22
============================================================

SPEEDUP:
  Polars (Python) vs Pandas: 11.08x mais rápido
  Polars (Rust) vs Pandas: 6.24x mais rápido
  Polars (Rust) vs Polars (Python): 0.56x mais rápido

REDUÇÃO DE MEMÓRIA:
  Polars (Python) vs Pandas: 60.2% menos memória
  Polars (Rust) vs Pandas: 60.1% menos memória

Conclusão

Quando comecei este artigo, prometi mostrar por que Polars está revolucionando o processamento de dados. Os números não mentem - e eles são ainda mais impressionantes do que esperava.

Os Resultados em Números

Processando 3 milhões de registros com operações reais (filtros, agregações, transformações e joins), foi obtido:

Python + Pandas:

Tempo total: 3.93 segundos
Memória pico: 782.39 MB

Python + Polars:

Tempo total: 0.35 segundos → 11.08x mais rápido
Memória pico: 311.11 MB → 60.2% menos memória

Rust + Polars:

Tempo total: 0.63 segundos → 6.24x mais rápido
Memória pico: 312.22 MB → 60.1% menos memória

O Que Esses Números Significam?

1. Polars é Consistentemente Mais Rápido

Com 11x de ganho de performance, Polars em Python transformou uma operação que levava quase 4 segundos em apenas 0.35 segundos. Em termos práticos:

Uma análise que levava 10 minutos agora leva menos de 1 minuto
Um pipeline que rodava em 1 hora agora termina em 5 minutos
Processamentos noturnos de 8 horas podem ser reduzidos para menos de 1 hora

2. Eficiência de Memória é Revolucionária

A redução de 60% no uso de memória não é apenas um número - é a diferença entre:

Precisar de uma máquina com 32GB vs 16GB de RAM
Conseguir processar datasets 2-3x maiores na mesma infraestrutura
Reduzir custos de nuvem significativamente em ambientes de produção

3. Lazy Evaluation é Magia Pura

Observe os tempos do Rust + Polars:

1. Lendo CSV (lazy)...          23.295µs (0.000023 segundos!)
2. Aplicando filtros...         206.271µs (0.0002 segundos!)
3. Agregações (groupby)...      13.338µs (0.000013 segundos!)
4. Transformações de colunas... 4.626µs (0.000004 segundos!)
5. Join de dataframes...        14.751µs (0.000014 segundos!)
6. Execução + escrita...        618.259ms (0.618 segundos)

As operações 1-5 levaram microsegundos porque Polars apenas construiu o plano de execução - não processou nada ainda. Quando finalmente executou (operação 6), fez tudo de uma vez, otimizado.

É como ter um assistente que anota todas as suas tarefas, reorganiza da forma mais eficiente possível, e então executa tudo de uma vez só.

4. Rust vs Python: Uma Surpresa Interessante

Curiosamente, Polars em Python foi mais rápido (0.35s) que em Rust puro (0.63s) no tempo total. Por quê? A maior parte do tempo do Rust foi gasto na escrita final do arquivo (618ms). As operações de processamento em si foram absurdamente rápidas em ambos.
Isso nos ensina algo importante: para a maioria dos casos de uso, Polars em Python já é mais que suficiente. Você não precisa migrar para Rust para ter ganhos extraordinários de performance.

O Veredicto Final

Polars não é hype - é uma mudança de paradigma.
Se você trabalha com dados e ainda usa apenas Pandas:

Para prototipagem e datasets pequenos: Pandas continua sendo excelente
Para qualquer coisa em produção: Polars deveria ser sua escolha padrão
Para datasets grandes (>1GB): Polars não é opcional, é necessário
Para economia de recursos: 60% menos memória = custos menores

Critério	Pandas	Polars
Performance	Significativamente mais lenta	Extremamente Rápida (11x mais)
Tipagem	Flexível (pode levar a erros)	Estrita (segurança e performance)
Paralelismo	Limitado (single-core padrão)	Nativo (aproveita todos os cores)
Lazy Evaluation	❌ (processamento imediato)	✔ (otimização e eficiência)
Uso de RAM	Alto (782 MB)	Baixo (311 MB, 60% menos)
Streaming	❌ (requer dados em memória)	✔ (via lazy, para datasets grandes)
Ecossistema ML	Excelente (maduro)	Bom (crescendo rapidamente)

A Transição Vale a Pena?

A curva de aprendizado de Polars existe, sim. A sintaxe é diferente, o paradigma de expressões requer uma mudança de mentalidade. Mas os resultados falam por si:

11x mais rápido significa que o tempo que você investe aprendendo Polars se paga na primeira semana de uso
60% menos memória significa infraestrutura mais barata e capacidade de processar datasets maiores
API consistente e expressiva significa código mais limpo e manutenível a longo prazo

O Futuro é Rust, Mas Você Não Precisa Saber Rust

A beleza de Polars é que você colhe todos os benefícios do Rust (velocidade, segurança de memória, paralelização) escrevendo Python. É o melhor dos dois mundos.

E quando você realmente precisar daquele último bit de performance? A transição de Python para Rust com Polars é suave - a API é praticamente idêntica.

Os números provam: Polars entrega o que promete. Não é marketing, não é hype - é engenharia de qualidade resolvendo problemas reais.
Se você processa dados regularmente, especialmente em produção, não é mais uma questão de "devo aprender Polars?" mas sim "quando vou migrar?".

A revolução do processamento de dados já começou. E ela é escrita em Rust 🦀.

Quer Dominar Rust e Entender Como Polars Funciona Por Baixo dos Panos?

Se este artigo despertou sua curiosidade sobre como Polars consegue ser tão rápido, ou se você quer entender por que Rust está revolucionando o mundo da programação, temos algo especial para você.
"Desbravando Rust" é o guia definitivo para quem quer ir além do superficial e realmente dominar a linguagem que está por trás de ferramentas como Polars, Tokio, Servo e tantas outras que estão redefinindo performance e segurança.

O Que Você Vai Aprender:

Fundamentos sólidos: Do zero ao avançado, sem pular etapas essenciais
Performance real: Entenda como Rust elimina o overhead que torna Python lento
Safety sem garbage collector: Como Rust garante segurança de memória em compile-time
Concorrência sem medo: Paralelização nativa sem data races (o que torna Polars tão rápido)
Projetos práticos: Construa aplicações reais, incluindo processamento de dados como vimos neste artigo.

Se os números não mentem e o Polars é 11x mais rápido que Pandas, imagine o que você pode construir quando entende a linguagem que torna isso possível.

[pt-BR] Performance na prática: Um exemplo de real onde o Axum supera o FastAPI

Jose Luis da Cruz Junior — Tue, 14 Jul 2026 11:00:00 +0000

Por @zejuniortdr em Nov 16, 2025

Qual a stack perfeita para desenvolvimento? Essa é uma pergunta simples porém que trás muitas dúvidas, principalmente para quem está começando e a resposta nem sempre é óbvia: É a que resolve o problema da melhor maneira possível, consumindo menos recursos.

Claro que sempre existirão trade-offs, como por exemplo a curva de aprendizado, que pode ser maior uma determinada linguagem, principalmente quando esta é o Rust devido a sua forma única de trabalhar e as decisões de design da própria linguagem que é bem única em alguns pontos.

Neste post, a ideia é apresentar um exemplo prático onde através de um benchmark simples, é possível ver a diferença entre as duas.

O escopo do projeto

Criar uma API Rest com um único endpoint /api/v1/cep/{cep} que receberá via path param e retornará os dados de endereço do CEP informado. Para otimizar a velocidade e reduzir o acoplamento de um serviço externo, ao invés de depender 100% de uma API de terceiros, primeiro a requisição consultará no banco da própria aplicação, e somente em caso de não encontrar o registro, baterá no terceiro para retornar o dado solicitado e persistir no banco para uma consulta futura.

Ambiente do Execução

Hardware: Intel Core i7-2600K (8 cores) @ 3.80 GHz, 15.56 GiB RAM
Sistema Operacional: EndeavourOS (Arch Linux)
Banco de Dados: PostgreSQL em container Docker
Condições: Mesma máquina, mesma configuração de banco, mesmo padrão de cache

Stack Python:

Python 3.13
FastAPI 0.115.0
Uvicorn com 4 workers
psycopg (driver async)
httpx para requisições HTTP

Stack Rust

Rust 1.90
Axum 0.8.6
Tokio runtime padrão
sqlx para PostgreSQL
reqwest para requisições HTTP

Parâmetros do Teste:

20.000 requisições totais
Concorrência: 50 conexões simultâneas
Sem fase de warmup (cold start)
Padrão de acesso: cache miss inicial → consulta ViaCEP → cache hits subsequentes
Lib responsável para o teste de carga: Dril para ambos.

Resultados Quantitativos

Métrica	FastAPI (Python)	Axum (Rust)	Diferença
Requisições/segundo	1.356,92	2.773,98	2,04x
Tempo total de execução	14,7s	7,2s	2,04x
Tempo mediano	28ms	9ms	3,11x
Tempo médio	36ms	18ms	2,00x
Percentil 99	88ms	42ms	2,09x
Percentil 99.5	103ms	51ms	2,02x
Percentil 99.9	2.048ms	1.901ms	1,08x
Desvio padrão	97ms	96ms	~1,00x
Requisições falhadas	0	0	Ambas 100%

A implementação Rust apresentou throughput duas vezes superior e latência mediana três vezes menor em comparação com a implementação Python.

Análise dos Percentis

Comportamento Típico (Mediana)
A mediana de 9ms para Axum versus 28ms para FastAPI indica que, em condições normais de operação, a implementação Rust responde em aproximadamente um terço do tempo.

Comportamento sob Carga (P99)
O percentil 99 mostra que 99% das requisições da implementação Rust completam em até 42ms, enquanto a implementação Python atinge 88ms. Esta diferença é relevante para aplicações com requisitos de SLA rigorosos.

Casos Extremos (P99.9)
Ambas as implementações apresentam spikes similares no percentil 99.9 (~2 segundos). Este comportamento sugere que os outliers não são causados pelos frameworks, mas provavelmente por contenção no PostgreSQL ou latência externa da API ViaCEP.

Fatores Técnicos de Performance

Modelo de Compilação
Python 3.13 executa bytecode através de um interpretador, mesmo com o JIT experimental que oferece melhorias de 2-9%. Rust compila para código de máquina nativo otimizado, eliminando overhead de interpretação.

Concorrência e Paralelismo
FastAPI com múltiplos workers do Uvicorn distribui carga entre processos, mas cada worker possui seu próprio Global Interpreter Lock (GIL), limitando paralelismo real dentro de cada processo. Rust com Tokio utiliza multi-threading nativo sem restrições de lock global.

Gerenciamento de Memória
Python utiliza garbage collection com pausas imprevisíveis. Rust emprega ownership e borrowing, garantindo segurança de memória em tempo de compilação sem overhead de GC em runtime.

Ecossistema Assíncrono
Ambas as implementações utilizam I/O assíncrono, mas o ecossistema Rust (Tokio + sqlx + reqwest) foi projetado com async como padrão desde a origem, resultando em menor overhead de abstração.

Considerações sobre sqlx
É relevante notar que sqlx não é o driver PostgreSQL mais performático para Rust. Benchmarks do TechEmpower mostram que implementações com tokio-postgres direto alcançam posições significativamente superiores em rankings de performance, devido ao menor overhead de pool de conexões e prepared statements.

Estrutura dos Handlers

Implementação com FastAPI**


@app.get("/api/v1/cep/{cep}")
async def get_cep(cep: str):
    # Limpar CEP (remover hífen)
    cep_limpo = cep.replace("-", "")

    # Validar formato
    if len(cep_limpo) != 8 or not cep_limpo.isdigit():
        raise HTTPException(status_code=400, detail="CEP inválido")

    # Buscar no banco
    async with db_pool.connection() as conn:
        async with conn.cursor(row_factory=dict_row) as cur:
            await cur.execute(
                "SELECT * FROM ceps WHERE cep = %s",
                (cep_limpo,)
            )
            row = await cur.fetchone()

            if row:
                return dict(row)

    # Fallback para ViaCEP
    try:
        response = await http_client.get(f"{VIACEP_URL}/{cep_limpo}/json/")
        response.raise_for_status()
        data = response.json()

        # Verificar se CEP existe
        if "erro" in data:
            raise HTTPException(status_code=404, detail="CEP não encontrado")

        # Salvar no banco
        async with db_pool.connection() as conn:
            async with conn.cursor() as cur:
                await cur.execute("""
                    INSERT INTO ceps (
                        cep, logradouro, complemento, bairro,
                        localidade, uf, ibge, gia, ddd, siafi
                    ) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s)
                    ON CONFLICT (cep) DO NOTHING
                """, (
                    data.get("cep", "").replace("-", ""),
                    data.get("logradouro", ""),
                    data.get("complemento", ""),
                    data.get("bairro", ""),
                    data.get("localidade", ""),
                    data.get("uf", ""),
                    data.get("ibge", ""),
                    data.get("gia", ""),
                    data.get("ddd", ""),
                    data.get("siafi", "")
                ))
                await conn.commit()

        return data

    except httpx.HTTPError as e:
        raise HTTPException(status_code=503, detail=f"Erro ao consultar ViaCEP: {str(e)}")

Características técnicas:

Validação e serialização automática via Pydantic
Type hints opcionais verificados em runtime
Tratamento de exceções com try/except
Syntax concisa e expressiva

Implementação com Axum

pub async fn get_zipcode_handler(
    State(state): State<AppState>,
    Path(cep): Path<String>,
) -> Response {
    dotenv().ok();

    let sanitized_zipcode = match cep_service::validate_cep(&cep) {
        Ok(valid_cep) => valid_cep,
        Err(error_response) => return *error_response,
    };

    let search_zipcode_on_viacep = env::var("SEARCH_ZIPCODE_ON_VIACEP")
        .unwrap_or_else(|_| "false".to_string())
        .to_lowercase()
        == "true";

    let strategy = cep_service::SearchStrategy::WithFallback {
        enable_viacep: search_zipcode_on_viacep
    };

    let result = cep_service::execute_search(&state, &sanitized_zipcode, strategy).await;

    cep_service::search_result_to_response(result, "")
}

Serviço auxiliar

pub async fn execute_search(
        state: &AppState,
        cep: &str,
        strategy: SearchStrategy,
    ) -> SearchResult {
        match strategy {
            SearchStrategy::Single(provider) => match provider {
                Provider::Database => search_in_database(state, cep).await,
                Provider::ViaCep => search_in_viacep(state, cep, Some(false)).await,
            },
            SearchStrategy::WithFallback {
                enable_viacep,
            } => match search_in_database(state, cep).await {
                SearchResult::Found(response) => SearchResult::Found(response),
                SearchResult::Error(err) => SearchResult::Error(err),
                SearchResult::NotFound => {
                    if enable_viacep {
                        match search_in_viacep(state, cep, Some(true)).await {
                            SearchResult::Found(response) => return SearchResult::Found(response),
                            SearchResult::Error(err) => return SearchResult::Error(err),
                            SearchResult::NotFound => {}
                        }
                    }
                    SearchResult::NotFound
                }
            },
        }
    }

pub async fn search_in_database(state: &AppState, cep: &str) -> SearchResult {
        let result = sqlx::query_as!(
            CepResponse,
            r#"
            SELECT
                l.cep,
                COALESCE(l.logradouro, '') as "logradouro!",
                COALESCE(b.nome, '') as "bairro!",
                c.nome as "cidade!",
                e.sigla as "estado!",
                l.created_at,
                'database' as "provider!: String"
            FROM logradouro l
            INNER JOIN cidade c ON l.id_cidade = c.id
            INNER JOIN estado e ON c.id_estado = e.id
            LEFT JOIN bairro b ON l.id_bairro = b.id
            WHERE l.cep = $1
            "#,
            cep
        )
        .fetch_optional(&state.db)
        .await;

        match result {
            Ok(Some(response)) => {
                tracing::info!("Found zipcode in database: {}", cep);
                SearchResult::Found(response)
            }
            Ok(None) => {
                tracing::info!("CEP não encontrado no banco: {}", cep);
                SearchResult::NotFound
            }
            Err(e) => {
                tracing::error!("Erro ao consultar banco de dados: {}", e);
                SearchResult::Error(format!("Erro ao consultar banco de dados: {}", e))
            }
        }
    }

    /// Busca CEP no ViaCep
    pub async fn search_in_viacep(
        state: &AppState,
        cep: &str,
        save_in_db: Option<bool>,
    ) -> SearchResult {
        let viacep_client: ViaCepClient = ViaCepClient::new();
        let must_save = save_in_db.unwrap_or(true);

        match viacep_client.buscar_cep(cep).await {
            Ok(viacep_response) => {
                tracing::info!("CEP {} encontrado no ViaCep", cep);

                if !must_save {
                    return SearchResult::Found(viacep_response);
                }

                if let Err(e) = salvar_cep(state, &viacep_response).await {
                    tracing::error!("Erro ao salvar CEP {} no banco: {}", cep, e);
                }

                SearchResult::Found(viacep_response)
            }
            Err(err) => {
                match err {
                    CepApiError::CepNotFound => {
                        tracing::warn!("CEP {} não encontrado no ViaCep", cep);
                        SearchResult::NotFound
                    }
                    CepApiError::InvalidCep => {
                        tracing::warn!("CEP {} inválido", cep);
                        SearchResult::Error("CEP inválido".to_string())
                    }
                    CepApiError::RequestError(msg) => {
                        tracing::warn!("Erro de request no ViaCep: {}", msg);
                        SearchResult::NotFound // Trata como not found para continuar fallback
                    }
                    CepApiError::HttpError(code) => {
                        tracing::warn!("Erro HTTP no ViaCep: código {}", code);
                        SearchResult::NotFound // Trata como not found para continuar fallback
                    }
                    CepApiError::ParseError(msg) => {
                        tracing::warn!("Erro de parsing no ViaCep: {}", msg);
                        SearchResult::NotFound // Trata como not found para continuar fallback
                    }
                }
            }
        }
    }

Características técnicas:

Type safety absoluto verificado em compile-time
Pattern matching para tratamento de erros com Result<T, E>
Sistema de ownership previne erros de memória
Serialização zero-copy quando possível via serde

Casos de Uso para Cada Stack

Quando FastAPI é Adequado

Desenvolvimento Rápido: Para prototipagem e MVPs, onde velocidade de implementação é prioritária. O tempo de desenvolvimento em Python é significativamente menor.

Ecossistema Rico: Projetos que requerem integração com bibliotecas de machine learning (TensorFlow, PyTorch), data science (pandas, numpy) ou outras ferramentas do ecossistema Python.

Curva de Aprendizado: Equipes que precisam de produtividade imediata. Desenvolvedores júnior podem contribuir efetivamente com Python em dias, enquanto Rust requer semanas de aprendizado.

Gargalos Externos: Aplicações onde o tempo de processação é dominado por operações de I/O lentas (queries não otimizadas, APIs externas). Nestes casos, otimização da linguagem tem impacto marginal.

Quando Axum é Adequado

Alto Volume: Sistemas que precisam processar milhares de requisições por segundo, onde eficiência computacional impacta diretamente custos de infraestrutura.

Requisitos de Latência: APIs públicas ou microserviços internos com SLAs rigorosos de tempo de resposta.

Estabilidade de Longo Prazo: Sistemas que evoluem lentamente e se beneficiam de garantias de type safety e memory safety em compile-time.

Otimização de Custos: Ambientes onde a redução do número de servidores ou instâncias cloud resulta em economia significativa.

Reteste com FastAPI + Gunicorn (8 Workers)

Após a publicação inicial, o @gleberdiniz, depois de revisar o material, sugeriu testar a implementação FastAPI com configuração de produção usando Gunicorn com múltiplos workers, argumentando que a comparação seria mais justa ao explorar melhor o paralelismo disponível no hardware de 8 núcleos.

Configuração do Teste Revisado

Instalação das dependências:

pipenv install gunicorn uvicorn

Comando de execução:

gunicorn app:app \
  --workers 8 \
  --worker-class uvicorn.workers.UvicornWorker \
  --bind 0.0.0.0:8000

Parâmetros do teste:

Mesmos 20.000 requisições
Mesma concorrência de 50 conexões
Mesmo ambiente de hardware e banco de dados

Novos Resultados Quantitativos

Métrica	FastAPI (4 workers)	FastAPI (8 workers)	Axum (Rust)	Melhoria 8w vs 4w	Gap Axum vs 8w
Requisições/segundo	1.356,92	2.470,25	2.773,98	+82,0%	1,12x
Tempo total de execução	14,7s	8,1s	7,2s	-44,9%	1,12x
Tempo mediano	28ms	21ms	9ms	-25,0%	2,33x
Tempo médio	36ms	20ms	18ms	-44,4%	1,11x
Percentil 99	88ms	48ms	42ms	-45,5%	1,14x
Percentil 99.5	103ms	56ms	51ms	-45,6%	1,10x
Percentil 99.9	2.048ms	631ms	1.901ms	-69,2%	3,01x
Desvio padrão	97ms	33ms	96ms	-66,0%	2,91x

Análise dos Resultados Revisados

Throughput Comparável
Com 8 workers, FastAPI alcançou 2.470 req/s, reduzindo significativamente a diferença para o Axum (2.774 req/s). A vantagem do Rust diminuiu de 2,04x para apenas 1,12x em throughput bruto.

Latência Ainda Superior no Rust
Apesar do throughput próximo, a latência mediana do Axum (9ms) permanece 2,33x menor que o FastAPI com 8 workers (21ms). Esta diferença é crítica para aplicações sensíveis a tempo de resposta.

Percentis Altos Melhoraram Drasticamente
O P99.9 do FastAPI caiu de 2.048ms para 631ms, uma melhoria de 69%. Isto sugere que o gargalo anterior estava mais relacionado à saturação dos workers do que a limitações fundamentais da stack Python.

Estabilidade e Consistência
O desvio padrão do FastAPI caiu de 97ms para 33ms, indicando respostas mais consistentes. Curiosamente, o Axum manteve desvio padrão alto (96ms), provavelmente relacionado a outliers externos (banco de dados ou ViaCEP).

Também como sugestão do @gleberdiniz, foi refeito ambos os testes (Axum e FastAPI com 8 workers) monitorando cpu e memória.

Os três primeiros picos de CPU foram os testes com FastAPI e chegou até 90%, enqunto os três últimos foram com o Axum parando em 70% do consumo, uma diferença de 20% de CPU menor.

Já memória não apresentou picos relavantes, além do platô quase no fim do gráfico quando foi aberto o editor para rodar os testes e se manteve bem estável com 25% de uso para ambos.

Problema Crítico Encontrado: Esgotamento de Conexões

Ao final do teste com 8 workers, o seguinte erro foi registrado:

error connecting in 'pool-1': connection failed: connection to server at "127.0.0.1",
port 5432 failed: FATAL: sorry, too many clients already

Análise do Problema:
A configuração original do pool (min_size=10, max_size=20) multiplicada por 8 workers resulta em:

Mínimo: 80 conexões simultâneas
Máximo: 160 conexões simultâneas

O PostgreSQL padrão limita conexões em 100, causando esgotamento sob carga. Este é um problema clássico de tuning que afeta qualquer stack ao escalar horizontalmente.

Recomendações:

Ajustar pool por worker: min_size=2, max_size=5 (16-40 conexões totais)
Aumentar limite do PostgreSQL: max_connections=200 no postgresql.conf
Considerar PgBouncer para pooling externo em produção

Implicações para a Comparação Original

O teste inicial não foi justo?
Parcialmente. Com 4 workers, o FastAPI não utilizava plenamente o hardware de 8 núcleos. No entanto, a escolha de 4 workers foi intencional e documentada, refletindo uma configuração comum em ambientes de produção.

Por que 4 workers era a configuração inicial?
A fórmula (2 × núcleos) + 1 sugere 17 workers para 8 núcleos, mas na prática, desenvolvedores frequentemente usam configurações conservadoras para evitar contenção excessiva e simplificar debugging.

Qual configuração é mais realista?
Ambas são válidas dependendo do contexto:

4 workers: Mais estável, menor consumo de memória, debugging mais simples
8 workers: Maior throughput, requer tuning cuidadoso de recursos (conexões DB, file descriptors, memória)

Conclusão Revisada

Com configuração otimizada de 8 workers, o FastAPI demonstrou que Python pode alcançar throughput competitivo com Rust em aplicações I/O bound. A diferença de 12% em requisições por segundo torna-se marginal para muitas aplicações.

No entanto, três vantagens fundamentais do Axum permanecem:

Latência consistentemente menor: 2,33x melhor na mediana, crítico para APIs de baixa latência
Configuração mais simples: Não requer tuning complexo de workers e pools de conexão
Eficiência de recursos: Menor consumo de memória e CPU por requisição

A escolha entre as stacks deve considerar:

FastAPI: Ideal quando throughput é suficiente e velocidade de desenvolvimento/manutenção é prioritária
Axum: Necessário quando latência, eficiência de recursos ou escala extrema são requisitos críticos

O benchmark revisado reforça que otimização de deployment é tão importante quanto a escolha da linguagem. Uma stack "inferior" bem configurada pode superar uma stack "superior" mal configurada.

Conclusões Finais

Os testes demonstram que Rust com Axum oferece vantagens mensuráveis de performance, mas o gap não é tão dramático quanto benchmarks sintéticos sugerem. Em aplicações I/O bound reais, a diferença entre stacks bem configuradas tende a ser menor que em CPU-bound workloads.

A decisão técnica adequada depende do contexto específico de cada projeto: volume esperado de tráfego, requisitos de latência, expertise da equipe, velocidade de iteração necessária e restrições de custo operacional. O reteste com 8 workers demonstra que tuning adequado é frequentemente mais impactante que a escolha da linguagem.

Quer Dominar Rust e Entender como uma API com Axum pode ajudar a aumentar a performance?

O Que Você Vai Aprender:

Fundamentos sólidos: Do zero ao avançado, sem pular etapas essenciais
Performance real: Entenda como Rust elimina o overhead que torna Python lento
Safety sem garbage collector: Como Rust garante segurança de memória em compile-time
Concorrência sem medo: Paralelização nativa sem data races (o que torna Polars tão rápido)
Projetos práticos: Construa aplicações reais, incluindo processamento de dados como vimos neste artigo.

DEV Community: Jose Luis da Cruz Junior

[pt-BR] Lifetimes em Rust: Desvendando o Tempo de Vida das Variáveis para Pythonistas

Por @zejuniortdr em Abr 16, 2026

Introdução: O Tempo de Vida das Variáveis

Seção 1: O Problema que Lifetimes Resolvem

Referências e Borrowing

Seção 2: Anotação de Lifetimes na Prática

Sintaxe Básica

Lifetimes em Estruturas

Seção 3: Python vs Rust - Gerenciamento de Memória

Como Python Gerencia Tempo de Vida

Rust: Controle Explícito

Caso Prático: Construindo um Parser Seguro

Lifetime Elision e Múltiplos Lifetimes

Erros Comuns para Pythonistas

1. Esquecer de anotar lifetimes em funções que retornam referências

2. Tentar retornar referência para valor local

3. Subestimar o escopo de variáveis emprestadas

4. Confundir ownership com borrowing em estruturas

5. Ignorar lifetime elision

6. Não usar lifetimes em enums com referências

O Que Aprendemos

Python vs Rust: resumo da abordagem de memória

[pt-BR] Desvendando Iteradores e Closures em Rust: A Potência Funcional para Pythonistas

Por @zejuniortdr em Abr 04, 2026

Por Que Closures e Iteradores São Fundamentais?

Seção 1: Entendendo Closures em Rust

O Que São Closures?

Os Três Traits de Closures: Fn, FnMut e FnOnce

Closure com Estado Mutável

Captura de Variáveis: As Diferenças Cruciais

Seção 2: Dominando Iteradores em Rust

iter(), iter_mut() e into_iter(): Quando Usar Cada Um

FromIterator e IntoIterator: A Magia Por Trás dos Iteradores

As Poderosas Adaptações: map, filter, collect

Adaptadores Avançados: chain, step_by e take

Exemplo Prático: Processando Dados de Sensor

Seção 3: Avaliação Preguiçosa vs Avaliação Imediata

A Filosofia de Cada Linguagem

Exemplo de Performance

Zero-Cost Abstractions e Loop Fusion

Comparação com Python: Quando Cada Abordagem Brilha

List Comprehensions vs Iteradores Rust

Generators Python vs Iteradores Rust

Erros Comuns de Pythonistas em Rust

Conclusão: Por Que Rust Vale a Pena para Programação Funcional

O Que Aprendemos

[pt-BR] Concorrência e Paralelismo em Rust: Desvendando Threads e Async/Await para Pythonistas

Por @zejuniortdr em Abr 01, 2026

🧵 Introdução: O Desafio da Programação Concorrente

🔒 Seção 1: Threads em Rust - Safety Garantido pelo Sistema de Tipos

Threads Seguras por Padrão

O Sistema de Ownership como Guardião

⚡ Seção 2: Async/Await em Rust - Performance sem Bloqueio

O Paradigma Assíncrono

Runtime vs Biblioteca

🐍 Seção 3: Comparação com Python - GIL, Threads e Asyncio

A Maldição do GIL (Global Interpreter Lock)

IO-bound: Async vs Threads

🚀 Seção 4: Exemplo Prático - Servidor Web Concorrente

Versão Python com Flask + Threading

Versão Rust com Actix Web (Async)

Teste de Carga Simples

🤔 Quando Usar Threads vs Async/Await em Rust

Threads São Ideais Para:

Async/Await É Ideal Para:

Paralelismo de Dados com rayon

Comparação de Performance

⚠️ Erros Comuns de Pythonistas em Rust

1. Tentar Usar Threads para Tudo Como no Python

2. Esquecer de .await em Funções Async

3. Bloquear Threads de Execução com Operações CPU-intensivas

🎯 Conclusão: Por Que Rust Brilha em Concorrência

📚 O Que Aprendemos

[pt-BR] Desmistificando Traits em Rust: Herança para Pythonistas

Por @zejuniortdr em Mar 28, 2026

Introdução: Herança vs Composição

🧩 O que são Traits e como funcionam

Sintaxe básica de Traits

Traits com implementações padrão

`iter()`, `iter_mut()` e `into_iter()`: Quando Usar Cada Um

Paralelismo de Dados com `rayon`

2. Esquecer de `.await` em Funções Async

O que é `dyn`?