DEV Community: Jose Luis da Cruz Junior

[pt-BR] Desvendando Pattern Matching em Rust: Um Guia Prático para Pythonistas

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

Por @zejuniortdr em Mai 16, 2026

Se você vem do Python, está acostumado com estruturas condicionais como if-elif-else para controlar o fluxo do programa. Mas e se eu te disser que Rust possui uma ferramenta muito mais poderosa chamada pattern matching? Vamos explorar como essa funcionalidade revolucionária pode transformar sua maneira de escrever código.

Introdução: O Que é Pattern Matching?

Em Python, quando precisamos verificar múltiplas condições, geralmente escrevemos uma cadeia de if-elif-else. Funciona, mas pode ficar verboso e difícil de manter. Rust oferece o match, uma estrutura que permite comparar um valor contra uma série de padrões de forma limpa e expressiva.

# Python - abordagem tradicional
status = 404
if status == 200:
    print("OK")
elif status == 404:
    print("Não encontrado")
else:
    print("Erro desconhecido")

// Rust - pattern matching
let status = 404;
match status {
    200 => println!("OK"),
    404 => println!("Não encontrado"),
    _ => println!("Erro desconhecido"),
}

Note como o match do Rust é mais declarativo e menos propenso a erros do que a cadeia de if-elif-else do Python.

Seção 1: `match` vs `if-elif-else` - Comparação Lado a Lado

Exemplo Prático: Classificação de Números

Vamos resolver o mesmo problema nas duas linguagens: classificar um número como positivo, negativo ou zero.

# Python
numero = 5
if numero > 0:
    print("Positivo")
elif numero < 0:
    print("Negativo")
else:
    print("Zero")

// Rust
let numero = 5;
match numero.cmp(&0) {
    std::cmp::Ordering::Greater => println!("Positivo"),
    std::cmp::Ordering::Less => println!("Negativo"),
    std::cmp::Ordering::Equal => println!("Zero"),
}

Vantagem do Rust: O compilador garante que todos os casos possíveis são tratados. Se esquecermos o Ordering::Equal, o Rust não compila!

Seção 2: Destruturação de Enums e Structs - Poder Além do Python

Enums em Rust são muito mais poderosos que em Python. Combinados com pattern matching, tornam-se uma ferramenta incrível.

// Definindo um enum
enum Forma {
    Circulo(f64),
    Retangulo(f64, f64),
    Quadrado(f64),
}

// Pattern matching com destruturação
fn area(forma: Forma) -> f64 {
    match forma {
        Forma::Circulo(raio) => 3.14159 * raio * raio,
        Forma::Retangulo(largura, altura) => largura * altura,
        Forma::Quadrado(lado) => lado * lado,
    }
}

Em Python, precisaríamos usar classes e verificações de tipo, que são menos seguras e mais verbosas.

Seção 3: Pattern Matching com Guards - Condições Avançadas

Guards permitem adicionar condições extras aos padrões:

let numero = Some(42);
match numero {
    Some(x) if x > 50 => println!("Maior que 50"),
    Some(x) if x < 10 => println!("Menor que 10"),
    Some(x) => println!("Entre 10 e 50: {}", x),
    None => println!("Nenhum valor"),
}

Isso seria equivalente a vários if aninhados em Python, mas muito mais organizado.

Seção 4: @ Bindings - Capturando Valores Dentro de Padrões

Podemos capturar valores enquanto fazemos pattern matching:

enum Mensagem {
    Texto(String),
    Numero(i32),
}

fn processar(m: Mensagem) {
    match m {
        Mensagem::Texto(t) @ Mensagem::Texto(_) if t.len() > 10 => {
            println!("Texto longo: {}", t)
        }
        Mensagem::Texto(t) => println!("Texto: {}", t),
        Mensagem::Numero(n) => println!("Número: {}", n),
    }
}

Comparação com Python: Quando Usar `match` em Rust vs Alternativas em Python

Em Python, pattern matching foi adicionado na versão 3.10, mas é muito menos poderoso que o do Rust. Veja a diferença:

# Python 3.10+
match status:
    case 200:
        print("OK")
    case 404:
        print("Não encontrado")
    case _:
        print("Erro desconhecido")

Limitações do Python:

Não suporta destruturação complexa
Não tem verificações em tempo de compilação
Não trabalha bem com tipos customizados

Erros Comuns para Programadores Python

Esquecer o _: Em Rust, o _ é obrigatório para cobrir todos os casos. Em Python, o else é opcional.
Confundir com switch-case: O match do Rust é muito mais poderoso que um switch tradicional.
Ignorar enums: Muitos tentam replicar padrões OO do Python, quando enums com pattern matching são muitas vezes a solução melhor em Rust.

Exemplo Prático Completo: Sistema de Login

Vamos implementar um sistema simples de autenticação:

enum Usuario {
    Autenticado { nome: String, admin: bool },
    Convidado,
}

fn saudacao(usuario: Usuario) {
    match usuario {
        Usuario::Autenticado { nome, admin: true } => {
            println!("Bem-vindo administrador {}!", nome)
        }
        Usuario::Autenticado { nome, admin: false } => {
            println!("Bem-vindo {}!", nome)
        }
        Usuario::Convidado => println!("Por favor faça login"),
    }
}

O Que Aprendemos

Pattern matching é mais expressivo e seguro que cadeias de if-elif-else
O compilador do Rust garante que todos os casos são tratados
Podemos destruturar enums e structs de forma poderosa
Guards permitem condições adicionais nos padrões
@ bindings ajudam a capturar valores durante o matching

Se você quer se aprofundar ainda mais em Rust e descobrir como aproveitar ao máximo seus recursos avançados, não deixe de conferir o livro completo Desbravando Rust.

[pt-BR] Macros em Rust: Automatizando Código Além do que Python Permite

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

Por @zejuniortdr em Mai 12, 2026

Metaprogramação é a arte de escrever código que gera ou manipula outro código. Se você vem do Python, provavelmente já usou decoradores, metaclasses ou funções de geração de código para automatizar tarefas repetitivas. O Rust também oferece poderosas ferramentas de metaprogramação, mas com uma abordagem fundamentalmente diferente e mais segura: as macros.

Enquanto Python permite modificar o código em tempo de execução, Rust opera em tempo de compilação através de seu poderoso sistema de macros. Isso oferece vantagens significativas: verificação de tipos antecipada, maior segurança e melhor performance, já que todo o código é expandido antes do programa rodar.

Neste artigo, vamos explorar como as macros do Rust vão além do que Python permite, oferecendo um controle granular sobre a geração de código com segurança em tempo de compilação.

O Que São Macros e Por Que São Diferentes de Python

Em Python, a metaprogramação acontece principalmente em tempo de execução. Decoradores modificam funções, metaclasses controlam a criação de classes, e funções como eval() permitem executar strings como código. Isso é flexível, mas também pode levar a erros que só aparecem quando o programa está rodando.

Rust, por outro lado, realiza toda metaprogramação em tempo de compilação através de macros. Existem dois tipos principais:

Macros declarativas (com macro_rules!): Mais simples, funcionam como correspondência de padrões
Macros procedurais: Mais poderosas, permitem manipulação arbitrária de tokens

A principal diferença é que as macros Rust são higiênicas (não causam efeitos colaterais inesperados) e seguras (o compilador verifica todo o código gerado).

Macros Declarativas: Criando Seu Próprio `print!` 🛠️

Vamos começar com macros declarativas, que são mais fáceis de entender para iniciantes. Elas funcionam através do macro_rules! e permitem criar syntax extensions usando regras de correspondência de padrões.

Um Exemplo Básico: `meu_println!`

Em Python, estamos acostumados com print() sendo uma função simples. Em Rust, println! é na verdade uma macro! Vamos criar nossa própria versão simplificada:

// Define uma macro chamada meu_println
macro_rules! meu_println {
    // Primeira regra: sem argumentos (apenas println vazio)
    () => {
        println!()  // Chama a macro println! existente
    };

    // Segunda regra: com um ou mais argumentos
    // $($arg:tt)* captura qualquer token válido em Rust (tt = token tree),
    // tornando a macro flexível para diferentes padrões de entrada
    ($($arg:tt)*) => {
        println!($($arg)*)  // Repassa os argumentos para println!
    };
}

fn main() {
    meu_println!();  // Imprime uma linha em branco
    meu_println!("Olá, {}!", "mundo");  // Imprime: Olá, mundo!
    meu_println!("Valores: {}, {}, {}", 1, 2, 3);  // Múltiplos argumentos

    // ⚠️ Erro comum: esquecer o ! na chamada
    // meu_println("teste");   // Erro: função `meu_println` não encontrada
    // meu_println!("teste");  // ✅ Correto
}

O que está acontecendo aqui:

macro_rules! inicia a definição da macro
() define uma regra para quando a macro é chamada sem argumentos
$($arg:tt)* captura todos os tokens passados para a macro — tt (token tree) aceita qualquer token válido Rust, o que torna a macro extremamente flexível
$($arg)* expande os tokens capturados na chamada para println!

Comparação com Python

Em Python, poderíamos criar algo similar com uma função:

def meu_print(*args, **kwargs):
    if not args and not kwargs:
        print()
    else:
        print(*args, **kwargs)

# Exemplo de uso
meu_print()
meu_print("Olá, {}!".format("mundo"))
meu_print("Valores:", 1, 2, 3)

A diferença crucial é que a versão Python roda em tempo de execução, enquanto a macro Rust é expandida durante a compilação. O código Rust resultante não tem overhead de chamada de função extra.

Um Exemplo Mais Útil: `vetor!`

Vamos criar uma macro mais útil que simplifica a criação de vetores:

macro_rules! vetor {
    // Caso vazio: cria um Vec vazio
    () => {
        Vec::new()
    };

    // Caso com elementos: $x:expr captura uma expressão
    ($($x:expr),*) => {
        {
            let mut temp_vec = Vec::new();
            $(temp_vec.push($x);)*  // Expande para push() para cada expressão
            temp_vec
        }
    };

    // Caso com repetição: usa std::iter::repeat para criar múltiplos elementos iguais.
    // Funciona para tipos Copy e Clone sem necessidade de .clone() explícito.
    ($x:expr; $n:expr) => {
        std::iter::repeat($x).take($n).collect::<Vec<_>>()
    };
}

fn main() {
    let v1 = vetor!();        // Vec vazio
    let v2 = vetor!(1, 2, 3); // Vec com valores 1, 2, 3
    let v3 = vetor!("a"; 5);  // Vec com 5 strings "a"

    println!("{:?}", v1);  // []
    println!("{:?}", v2);  // [1, 2, 3]
    println!("{:?}", v3);  // ["a", "a", "a", "a", "a"]
}

Nota técnica: A versão anterior usava .clone() explícito dentro de um loop, o que é desnecessário para tipos Copy (como inteiros) e verboso para os demais. Usar std::iter::repeat é idiomático e deixa o compilador decidir a estratégia de cópia mais eficiente.

Em Python, teríamos que usar uma função normal:

def criar_vetor(*args):
    if len(args) == 0:
        return []
    elif len(args) == 2 and isinstance(args[1], int):
        return [args[0]] * args[1]
    else:
        return list(args)

# Exemplo de uso
v1 = criar_vetor()
v2 = criar_vetor(1, 2, 3)
v3 = criar_vetor("a", 5)

print(v1)  # []
print(v2)  # [1, 2, 3]
print(v3)  # ["a", "a", "a", "a", "a"]

A versão Rust é mais poderosa porque:

Verifica tipos em tempo de compilação
Não tem overhead de runtime (a macro é expandida antes da execução)
Oferece syntax mais limpa com múltiplos padrões

Macros Procedurais: O Poder Real da Metaprogramação 💪

⚠️ Atenção: Macros procedurais são um tópico avançado e requerem familiaridade com parsing de código Rust. Se você ainda está se familiarizando com a linguagem, comece com macros declarativas e volte aqui quando se sentir confortável com os fundamentos!

As macros procedurais são muito mais poderosas que as declarativas. Elas permitem manipular arbitrariamente o código fonte usando a API de tokens do Rust. Existem três tipos:

Macros de Derive: Automatizam implementação de traits
Macros de Atributo: Aplicam transformações a itens
Macros Function-like: Parecidas com as declarativas, mas com poder total sobre os tokens

Configuração para Macros Procedurais

Para criar macros procedurais, precisamos de uma crate especial. Vamos configurar:

Cargo.toml:

[package]
name = "meu_projeto"
version = "0.1.0"
edition = "2021"

[lib]
# Esta linha é crucial: define que esta crate pode exportar macros procedurais.
# Macros procedurais requerem esta configuração especial porque o compilador
# precisa carregar e executar sua crate durante a própria compilação do projeto.
proc-macro = true

[dependencies]
syn = { version = "2.0", features = ["full"] }
quote = "1.0"
proc-macro2 = "1.0"

Macro de Derive: `MinhaSerde`

Vamos criar uma macro de derive simples que automaticamente gera serialização básica, similar ao que o Serde faz:

// main.rs
use minha_serde::MinhaSerde;

#[derive(MinhaSerde)]
struct Pessoa {
    nome: String,
    idade: u32,
    ativo: bool,
}

fn main() {
    let pessoa = Pessoa {
        nome: "João".to_string(),
        idade: 30,
        ativo: true,
    };

    let serializado = pessoa.serializar();
    println!("{}", serializado);
    // {"nome": "João", "idade": 30, "ativo": true}
}

// lib.rs da crate minha_serde
use proc_macro::TokenStream;
use proc_macro2::Span;
use quote::quote;
use syn::{parse_macro_input, DeriveInput};

#[proc_macro_derive(MinhaSerde)]
pub fn minha_serde_derive(input: TokenStream) -> TokenStream {
    // Parse do input para AST
    let input = parse_macro_input!(input as DeriveInput);
    let nome = input.ident;

    // Extrai os campos da struct
    let campos = if let syn::Data::Struct(syn::DataStruct {
        fields: syn::Fields::Named(ref campos_nomeados),
        ..
    }) = input.data {
        &campos_nomeados.named
    } else {
        // ✅ Retorna um erro de compilação em vez de um panic em runtime
        return syn::Error::new(
            Span::call_site(),
            "MinhaSerde só funciona com structs com campos nomeados!"
        ).to_compile_error().into();
    };

    // Gera os nomes dos campos como strings e os identificadores para acesso
    let nomes_campos: Vec<String> = campos
        .iter()
        .map(|campo| campo.ident.as_ref().unwrap().to_string())
        .collect();

    let idents_campos: Vec<_> = campos
        .iter()
        .map(|campo| campo.ident.as_ref().unwrap())
        .collect();

    // Gera a implementação do trait.
    // Nota: usamos `{}` (Display) em vez de `{:?}` (Debug) para serialização.
    // Isso exige que cada campo implemente o trait `Display`.
    // Para um serializador real, use a crate `serde` com suporte a tipos arbitrários.
    let expandido = quote! {
        impl #nome {
            pub fn serializar(&self) -> String {
                let mut resultado = String::from("{");
                #(
                    resultado.push_str(&format!("\"{}\": {}, ", #nomes_campos, self.#idents_campos));
                )*
                resultado.pop();  // Remove última vírgula
                resultado.pop();  // Remove último espaço
                resultado.push('}');
                resultado
            }
        }
    };

    TokenStream::from(expandido)
}

Nota técnica: Usamos syn::Error::new(...).to_compile_error() em vez de panic!(). Isso garante que o erro apareça como um erro de compilação limpo e rastreável, em vez de um crash do compilador — que é o comportamento esperado em macros procedurais de produção.

Este exemplo mostra o poder real das macros procedurais: analisamos a estrutura da struct em tempo de compilação e geramos código específico baseado em seus campos.

Comparação com Python

Em Python, usaríamos decoradores de classe ou metaclasses para funcionalidade similar:

def minha_serde(cls):
    def serializar(self):
        campos = []
        for nome, valor in self.__dict__.items():
            campos.append(f'"{nome}": {repr(valor)}')
        return "{" + ", ".join(campos) + "}"

    cls.serializar = serializar
    return cls

@minha_serde
class Pessoa:
    def __init__(self, nome, idade, ativo):
        self.nome = nome
        self.idade = idade
        self.ativo = ativo

# Exemplo de uso
pessoa = Pessoa("João", 30, True)
print(pessoa.serializar())  # {"nome": "João", "idade": 30, "ativo": True}

As diferenças são fundamentais:

A versão Rust verifica tipos em tempo de compilação
O código Rust gerado é otimizado especificamente para cada struct
Não há overhead de runtime para análise reflexiva
Erros são detectados durante a compilação, não durante a execução

Macro Function-like Procedural

Além das macros de derive e atributo, existe o terceiro tipo: macros function-like procedurais. Elas têm a mesma sintaxe de chamada das declarativas (nome!(...)), mas com poder total sobre os tokens de entrada:

// lib.rs
use proc_macro::TokenStream;

#[proc_macro]
pub fn meu_sql(input: TokenStream) -> TokenStream {
    // Aqui você pode validar SQL em tempo de compilação,
    // gerar structs de resultado, etc.
    let sql = input.to_string();
    quote::quote! {
        compile_error!(concat!("SQL processado em compile-time: ", #sql))
    }.into()
}

// Uso
meu_sql!(SELECT * FROM usuarios WHERE ativo = true);

Esse padrão é usado por crates como sqlx para validar queries SQL contra o banco de dados em tempo de compilação — algo simplesmente impossível em Python.

Macros de Atributo: Personalizando Comportamento

Macros de atributo permitem criar atributos personalizados que modificam itens. Vamos criar um atributo medir_tempo que automaticamente mede o tempo de execução de funções:

// main.rs
use medir_tempo::medir_tempo;

#[medir_tempo]
fn funcao_lenta() {
    std::thread::sleep(std::time::Duration::from_secs(1));
    println!("Função executada!");
}

fn main() {
    funcao_lenta();
    // Imprime: "funcao_lenta levou 1.003s"
}

// lib.rs da crate medir_tempo
use proc_macro::TokenStream;
use quote::quote;
use syn::{parse_macro_input, ItemFn};

#[proc_macro_attribute]
pub fn medir_tempo(_attr: TokenStream, item: TokenStream) -> TokenStream {
    let input = parse_macro_input!(item as ItemFn);
    let nome_funcao = &input.sig.ident;
    let blocos = &input.block;
    let visibilidade = &input.vis;
    let assinatura = &input.sig;

    let expandido = quote! {
        #visibilidade #assinatura {
            let inicio = std::time::Instant::now();
            let resultado = (|| #blocos)();
            let duracao = inicio.elapsed();
            println!("{} levou {:.3}s", stringify!(#nome_funcao), duracao.as_secs_f64());
            resultado
        }
    };

    TokenStream::from(expandido)
}

Comparação com Python

Em Python, usaríamos um decorador normal:

import time

def medir_tempo(funcao):
    def wrapper(*args, **kwargs):
        inicio = time.time()
        resultado = funcao(*args, **kwargs)
        duracao = time.time() - inicio
        print(f"{funcao.__name__} levou {duracao:.3f}s")
        return resultado
    return wrapper

@medir_tempo
def funcao_lenta():
    time.sleep(1)
    print("Função executada!")

funcao_lenta()  # "funcao_lenta levou 1.003s"

Novamente, a diferença fundamental está em quando a transformação acontece:

Python: Em tempo de execução, com overhead de chamadas de função
Rust: Em tempo de compilação, sem overhead de runtime

Debugando Macros com `cargo-expand`

Uma das partes mais desafiadoras de trabalhar com macros é entender o que elas realmente geram. A ferramenta cargo-expand resolve exatamente isso, mostrando o código final após todas as expansões:

# Instalação (necessária apenas uma vez)
cargo install cargo-expand

# Ver o código expandido do seu projeto
cargo expand

# Ver apenas um módulo específico
cargo expand meu_modulo

Por exemplo, ao rodar cargo expand em um projeto que usa #[derive(MinhaSerde)], você verá exatamente o código impl Pessoa { pub fn serializar(...) } gerado pela macro — o que é invaluável para debugging e aprendizado.

Quando Não Usar Macros

Antes de sair criando macros para tudo, é importante saber quando não usá-las:

Dificultam o debugging: Erros em código gerado por macros podem ter mensagens confusas e stack traces difíceis de rastrear
Reduzem a legibilidade: Um código com muitas macros pode ser difícil de entender para quem não as escreveu
São complexas de manter: Macros procedurais especialmente exigem conhecimento de syn, quote e a API de tokens do Rust
IDEs têm suporte limitado: Autocomplete e navegação de código funcionam melhor com código direto

Regra de ouro: Se uma função, trait ou genérico resolve o problema, prefira essas opções. Reserve macros para quando a sintaxe ou a geração de código em tempo de compilação for realmente necessária.

Erros Comuns de Pythonistas em Rust

Esquecer o ! na chamada: Macros parecem funções, mas a exclamação é obrigatória.

   meu_println("teste");   // ❌ Erro: função não encontrada
   meu_println!("teste");  // ✅ Correto

Tentar usar macros como funções: Têm regras diferentes — não aceitam tipos genéricos da mesma forma.
Esquecer da higiene: Macros Rust são higiênicas (variáveis não vazam para o escopo externo), ao contrário de algumas técnicas de metaprogramação Python.
Subestimar a complexidade: Macros procedurais são mais complexas que decoradores Python. Use cargo expand para entender o que está sendo gerado.
Usar panic! em macros procedurais: Prefira syn::Error::new(...).to_compile_error() para produzir erros de compilação adequados.

Quando Usar Macros no Rust

Use macros quando:

Você precisa de boilerplate repetitivo que não pode ser abstraído com funções ou traits
Quer criar APIs com syntax personalizada (como vec![] ou println!)
Precisa de código gerado em tempo de compilação para performance
Está implementando traits comuns para muitos tipos automaticamente

O Que Aprendemos

Macros declarativas (macro_rules!) permitem criação de syntax extensions através de regras de pattern matching
Macros procedurais oferecem poder total sobre manipulação de código em três variedades: derive, attribute e function-like
Macros de derive automatizam implementação de traits com base na análise de estruturas em tempo de compilação
Macros de atributo modificam itens anotados com comportamentos personalizados
Macros function-like procedurais permitem processamento arbitrário de tokens, como validação de SQL em compile-time
cargo expand é a ferramenta essencial para debugar e entender o código gerado pelas macros
O processo de compilação do Rust expande macros antes da geração de código, oferecendo segurança e performance
Comparação com Python: Enquanto Python usa runtime metaprogramming (decoradores, metaclasses), Rust faz compile-time metaprogramming com verificação de tipos — e isso faz toda a diferença

As macros são uma das características mais poderosas do Rust, permitindo criar código conciso, seguro e eficiente que seria impossível ou inseguro em muitas outras linguagens. Use-as com sabedoria, sempre preferindo a solução mais simples quando ela resolver o problema.

Este artigo é um material de apoio do livro Desbravando Rust, que explora em profundidade todos esses conceitos e muitos outros. Se você quer dominar Rust vindo de background Python, compre agora em desbravandorust.com.br e acelere sua jornada Rust!

[pt-BR] Smart Pointers em Rust: Gerenciamento Avançado de Memória para Pythonistas

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

Por @zejuniortdr em Abr 18, 2026

Se você vem do Python, onde o gerenciamento de memória é automático através do coletor de lixo (GC), pode estranhar inicialmente como Rust lida com alocação e liberação de memória. Porém, os Smart Pointers em Rust oferecem um meio-termo poderoso: controle manual quando necessário, mas com segurança garantida pelo compilador. Vamos explorar como essas estruturas funcionam e como se comparam ao modelo Python.

Introdução: Do Python para Rust - Uma Mudança de Paradigma

Em Python, você nunca precisa se preocupar explicitamente em alocar ou liberar memória. O interpretador cuida disso para você através de:

Contagem de referências (para objetos imediatamente destruíveis)
Coletor de lixo (para detectar ciclos não acessíveis)

Já em Rust, não temos um GC tradicional. Em vez disso, usamos um sistema de propriedade (ownership) combinado com Smart Pointers - estruturas que gerenciam a alocação de memória de forma segura e previsível.

Principais diferenças:

Python	Rust
Gerenciamento automático	Controle manual com garantias
Coletor de lixo overhead	Sem runtime overhead
Pode vazar memória por ciclos	Sem vazamentos (com `Rc`/`Arc` + `Weak`)
Tudo é referência	Escolha explícita entre stack/heap

Entendendo `Box<T>` - Alocação heap simplificada

O Box é o Smart Pointer mais simples em Rust. Ele permite alocar valores no heap (área de memória dinâmica) enquanto mantém um ponteiro para esse valor na stack (pilha de execução).

Analogia Python

Em Python, praticamente tudo vai para o heap automaticamente:

class Node:
    def __init__(self, value):
        self.value = value
        self.next = None

# Tudo alocado no heap, gerenciado pelo Python
node = Node(42)

Em Rust, precisamos ser explícitos:

struct Node {
    value: i32,
    next: Option<Box<Node>>, // Box permite alocação heap
}

fn main() {
    // Aloca um Node no heap, retorna um Box que aponta para ele
    let node = Box::new(Node {
        value: 42,
        next: None,
    });

    // node será automaticamente desalocado quando sair do escopo
}

Por que usar `Box`?

Quando você tem um tipo cujo tamanho não é conhecido em tempo de compilação (como recursão)
Para transferir ownership de grandes estruturas sem copiar
Quando precisa armazenar um trait object (Box<dyn Trait>)

`Rc<T>` e `Arc<T>` - Contagem de referências estilo Python, mas seguro

Python usa contagem de referências para gerenciar a vida útil dos objetos. Rust oferece algo similar com Rc (Reference Counting), porém com garantias em tempo de compilação.

Comparação direta

Python:

import sys

x = [1, 2, 3]
y = x  # Nova referência ao mesmo objeto
print(sys.getrefcount(x))  # Mostra 3 (x, y + temporário no getrefcount)

Rust:

use std::rc::Rc;

fn main() {
    let x = Rc::new(vec![1, 2, 3]);
    let y = Rc::clone(&x); // Incrementa contador

    println!("Contagem: {}", Rc::strong_count(&x)); // Mostra 2
} // x e y são desalocados aqui

Diferenças cruciais

Rc é somente leitura - você não pode modificar o conteúdo diretamente (precisa de RefCell para isso)
Arc (Atomic Reference Counting) é a versão thread-safe
Rust detecta ciclos em tempo de compilação (ao contrário do Python)

Erro comum de Pythonistas

Tentar usar Rc como substituição direta das referências do Python:

// ERRADO: Tentar modificar diretamente
let x = Rc::new(String::from("hello"));
x.push_str(" world"); // Erro de compilação: Rc não permite mutação

Solução correta (com RefCell que veremos a seguir):

use std::cell::RefCell;

let x = Rc::new(RefCell::new(String::from("hello")));
x.borrow_mut().push_str(" world"); // OK

`RefCell<T>` e `Mutex<T>` - Flexibilidade controlada de mutabilidade

Enquanto Python permite mutação livre de objetos (mesmo quando compartilhados), Rust exige que você seja explícito sobre mutabilidade compartilhada.

`RefCell<T>` - Mutabilidade interior

Permite "emprestar" referências mutáveis mesmo quando o próprio RefCell é imutável, com verificações em tempo de execução.

Exemplo prático:

use std::cell::RefCell;

struct Banco {
    saldo: RefCell<f64>,
}

impl Banco {
    fn depositar(&self, valor: f64) {
        *self.saldo.borrow_mut() += valor;
    }

    fn sacar(&self, valor: f64) -> Result<(), String> {
        let mut saldo = self.saldo.borrow_mut();
        if *saldo >= valor {
            *saldo -= valor;
            Ok(())
        } else {
            Err("Saldo insuficiente".to_string())
        }
    }
}

fn main() {
    let conta = Banco { saldo: RefCell::new(100.0) };
    conta.depositar(50.0);
    match conta.sacar(30.0) {
        Ok(_) => println!("Saque realizado"),
        Err(e) => println!("Erro: {}", e),
    }
    println!("Saldo final: {}", *conta.saldo.borrow());
}

`Mutex<T>` - Mutabilidade segura entre threads

Para concorrência, Rust oferece o Mutex, que garante acesso exclusivo entre threads.

Comparação com Python:

# Python: Mutex manual com Lock
from threading import Lock

class Contador:
    def __init__(self):
        self.valor = 0
        self.lock = Lock()

    def incrementar(self):
        with self.lock:
            self.valor += 1

// Rust: Mutex encapsula o valor
use std::sync::{Arc, Mutex};
use std::thread;

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

    for _ in 0..10 {
        let contador = Arc::clone(&contador);
        let handle = thread::spawn(move || {
            let mut num = contador.lock().unwrap();
            *num += 1;
        });
        handles.push(handle);
    }

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

    println!("Resultado: {}", *contador.lock().unwrap());
}

Comparação com Python: Como os Smart Pointers substituem o GC mantendo segurança

Cenário	Python	Rust
Objeto único	Referência direta	`Box` ou ownership direto
Compartilhamento	Referências múltiplas	`Rc`/`Arc` + `RefCell`/`Mutex`
Mutabilidade	Livre	Controlada (`RefCell`/`Mutex`)
Ciclos	GC resolve	`Weak` para quebrar ciclos
Thread safety	GIL ou locks manuais	`Arc<Mutex<T>>` ou `Arc<RwLock<T>>`

Quando usar cada Smart Pointer

Box<T>:
- Tipos de tamanho desconhecido (recursão, trait objects)
- Transferir ownership de grandes dados sem cópia
Rc<T> + RefCell<T>:
- Estruturas de dados com múltiplos proprietários
- Grafos ou árvores onde os nós são compartilhados
- Apenas para uso single-threaded
Arc<T> + Mutex<T>/RwLock<T>:
- Compartilhamento entre threads
- Caches compartilhados ou estados globais
Cow<T> (Clone on Write):
- Otimização para evitar cópias desnecessárias
- Útil quando você pode precisar modificar, mas na maioria não modifica

Exemplo Prático Completo: Sistema de Arquivos Simulado

Vamos implementar uma estrutura de diretórios que pode ser compartilhada:

use std::rc::{Rc, Weak};
use std::cell::RefCell;

#[derive(Debug)]
struct Arquivo {
    nome: String,
    tamanho: usize,
}

#[derive(Debug)]
struct Diretorio {
    nome: String,
    arquivos: RefCell<Vec<Arquivo>>,
    subdiretorios: RefCell<Vec<Rc<Diretorio>>>,
    pai: RefCell<Weak<Diretorio>>,
}

impl Diretorio {
    fn new(nome: &str) -> Rc<Self> {
        Rc::new(Self {
            nome: nome.to_string(),
            arquivos: RefCell::new(vec![]),
            subdiretorios: RefCell::new(vec![]),
            pai: RefCell::new(Weak::new()),
        })
    }

    fn adicionar_subdiretorio(self: &Rc<Self>, subdir: &Rc<Diretorio>) {
        *subdir.pai.borrow_mut() = Rc::downgrade(self);
        self.subdiretorios.borrow_mut().push(Rc::clone(subdir));
    }

    fn adicionar_arquivo(&self, nome: &str, tamanho: usize) {
        self.arquivos.borrow_mut().push(Arquivo {
            nome: nome.to_string(),
            tamanho,
        });
    }

    fn tamanho_total(&self) -> usize {
        let arquivos = self.arquivos.borrow();
        let subdirs = self.subdiretorios.borrow();

        let tamanho_arquivos: usize = arquivos.iter().map(|a| a.tamanho).sum();
        let tamanho_subdirs: usize = subdirs.iter().map(|d| d.tamanho_total()).sum();

        tamanho_arquivos + tamanho_subdirs
    }
}

fn main() {
    let raiz = Diretorio::new("raiz");

    let documentos = Diretorio::new("documentos");
    raiz.adicionar_subdiretorio(&documentos);

    let fotos = Diretorio::new("fotos");
    raiz.adicionar_subdiretorio(&fotos);

    documentos.adicionar_arquivo("relatorio.txt", 150);
    fotos.adicionar_arquivo("ferias.jpg", 2500);

    println!("Tamanho total: {} bytes", raiz.tamanho_total());

    // Demonstração da hierarquia pai-filho
    if let Some(pai) = documentos.pai.borrow().upgrade() {
        println!("O pai de 'documentos' é '{}'", pai.nome);
    }
}

O que aprendemos

Box<T> é o ponteiro mais simples, para alocar valores no heap quando necessário
Rc<T> e Arc<T> implementam contagem de referências como Python, mas com garantias de segurança
RefCell<T> permite mutabilidade controlada com verificações em tempo de execução
Mutex<T> e RwLock<T> são as versões thread-safe para compartilhamento seguro
Rust oferece mais controle que Python sobre gerenciamento de memória, sem abrir mão da segurança
Smart Pointers em Rust substituem muitas funções do GC do Python, mas com menos overhead

Erros comuns de Pythonistas

Tentar usar Rc como substituição direta das referências do Python sem RefCell
Esquecer que Rc não é thread-safe (precisa usar Arc para concorrência)
Criar ciclos de referência sem usar Weak (que pode levar a vazamentos)
Tentar modificar dados dentro de um Rc diretamente, sem passar por RefCell ou Mutex

Conclusão: Por que Smart Pointers em Rust?

Enquanto Python abstrai completamente o gerenciamento de memória, Rust oferece um meio-termo poderoso com os Smart Pointers. Eles permitem:

Controle preciso sobre alocações heap
Compartilhamento seguro de dados
Mutabilidade controlada e verificada
Zero-cost abstractions (sem overhead em runtime)

Para quem vem do Python, pode parecer complexo inicialmente, mas os benefícios em performance e segurança valem o esforço de aprendizado.

Quer se aprofundar ainda mais em Rust? Confira o livro completo Desbravando Rust onde exploramos todos esses conceitos com exemplos práticos e exercícios progressivos.

[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.

DEV Community: Jose Luis da Cruz Junior

[pt-BR] Desvendando Pattern Matching em Rust: Um Guia Prático para Pythonistas

Por @zejuniortdr em Mai 16, 2026

Introdução: O Que é Pattern Matching?

Seção 1: match vs if-elif-else - Comparação Lado a Lado

Exemplo Prático: Classificação de Números

Seção 2: Destruturação de Enums e Structs - Poder Além do Python

Seção 3: Pattern Matching com Guards - Condições Avançadas

Seção 4: @ Bindings - Capturando Valores Dentro de Padrões

Comparação com Python: Quando Usar match em Rust vs Alternativas em Python

Erros Comuns para Programadores Python

Exemplo Prático Completo: Sistema de Login

O Que Aprendemos

[pt-BR] Macros em Rust: Automatizando Código Além do que Python Permite

Por @zejuniortdr em Mai 12, 2026

O Que São Macros e Por Que São Diferentes de Python

Macros Declarativas: Criando Seu Próprio print! 🛠️

Um Exemplo Básico: meu_println!

Comparação com Python

Um Exemplo Mais Útil: vetor!

Macros Procedurais: O Poder Real da Metaprogramação 💪

Configuração para Macros Procedurais

Macro de Derive: MinhaSerde

Comparação com Python

Macro Function-like Procedural

Macros de Atributo: Personalizando Comportamento

Comparação com Python

Debugando Macros com cargo-expand

Quando Não Usar Macros

Erros Comuns de Pythonistas em Rust

Quando Usar Macros no Rust

O Que Aprendemos

[pt-BR] Smart Pointers em Rust: Gerenciamento Avançado de Memória para Pythonistas

Por @zejuniortdr em Abr 18, 2026

Introdução: Do Python para Rust - Uma Mudança de Paradigma

Entendendo Box<T> - Alocação heap simplificada

Analogia Python

Por que usar Box?

Rc<T> e Arc<T> - Contagem de referências estilo Python, mas seguro

Comparação direta

Diferenças cruciais

Erro comum de Pythonistas

RefCell<T> e Mutex<T> - Flexibilidade controlada de mutabilidade

RefCell<T> - Mutabilidade interior

Mutex<T> - Mutabilidade segura entre threads

Comparação com Python: Como os Smart Pointers substituem o GC mantendo segurança

Quando usar cada Smart Pointer

Exemplo Prático Completo: Sistema de Arquivos Simulado

O que aprendemos

Erros comuns de Pythonistas

Conclusão: Por que Smart Pointers em Rust?

[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

Seção 1: `match` vs `if-elif-else` - Comparação Lado a Lado

Comparação com Python: Quando Usar `match` em Rust vs Alternativas em Python

Macros Declarativas: Criando Seu Próprio `print!` 🛠️

Um Exemplo Básico: `meu_println!`

Um Exemplo Mais Útil: `vetor!`

Macro de Derive: `MinhaSerde`

Debugando Macros com `cargo-expand`

Entendendo `Box<T>` - Alocação heap simplificada

Por que usar `Box`?

`Rc<T>` e `Arc<T>` - Contagem de referências estilo Python, mas seguro

`RefCell<T>` e `Mutex<T>` - Flexibilidade controlada de mutabilidade

`RefCell<T>` - Mutabilidade interior

`Mutex<T>` - Mutabilidade segura entre threads

`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`?