Um dia na vida de um desenvolvedor Rust: do café da manhã ao cargo noturno

Manhã: código, café e compilador

No mundo da programação de sistemas, Rust ocupa um lugar especial. Ele combina a velocidade do C++ com a segurança de memória garantida pelo compilador em nível de tipos. Mas como é realmente o dia de trabalho de um desenvolvedor que programa em Rust? Esqueça os estereótipos sobre "programadores de sistemas chatos" — hoje vamos analisar um dia real na vida de um engenheiro Rust. Sem enfeites, com trechos reais de código e problemas reais.

Imagine: 9:00 da manhã. Você abre o notebook, inicia o terminal e vê uma mensagem do CI: "Build failed". Você suspira, executa cargo check e mergulha no mundo do borrow checker. Bem-vindo ao dia de um desenvolvedor Rust.

Manhã padrão: code review e tickets

A primeira coisa é verificar pull requests. Em equipes Rust, o code review é especialmente importante porque o compilador pega muitos erros, mas a lógica e a arquitetura são verificadas por pessoas. Você analisa o PR de um colega que adiciona um novo módulo para processamento de configuração.

// config.rs — parsing de configuração\nuse serde::Deserialize;\nuse std::path::Path;\n\n#[derive(Debug, Deserialize)]\nstruct AppConfig {\n    host: String,\n    port: u16,\n    max_connections: u32,\n    db_url: String,\n}\n\nfn load_config(path: impl AsRef<Path>) -> Result<AppConfig, ConfigError> {\n    let content = std::fs::read_to_string(path.as_ref())?;\n    let config: AppConfig = toml::from_str(&content)?;\n    Ok(config)\n}

Você percebe: não há verificação para strings vazias. Você adiciona um comentário: "E se host estiver vazio? Talvez adicionar validação com validator?" Após 15 minutos, o colega responde: "Concordo, adicionei #[validate]". O dia começa produtivo.

Parte principal: mergulho no código

10:00 — Trabalhando com assincronicidade e tokio

Você muda para sua tarefa: precisa reescrever um servidor HTTP que processa webhooks. O código antigo foi escrito com threads bloqueantes e está lento. Sua ferramenta é tokio e async/await. Rust é excelente para sistemas de alta carga, e você sabe disso.

Você escreve um novo handler:

use axum::{\n    routing::post,\n    Router,\n    Json,\n};\nuse serde_json::Value;\n\nasync fn handle_webhook(Json(payload): Json<Value>) -> String {\n    // Validação, processamento, escrita no BD\n    println!("Webhook recebido: {:?}", payload);\n    tokio::time::sleep(std::time::Duration::from_millis(100)).await;\n    "OK".to_string()\n}\n\n#[tokio::main]\nasync fn main() {\n    let app = Router::new()\n        .route("/webhook", post(handle_webhook));\n\n    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())\n        .serve(app.into_make_service())\n        .await\n        .unwrap();\n}

Você executa cargo run — sem erros. Rust provou sua confiabilidade novamente. Mas isso é só o começo.

11:30 — Batalha com o borrow checker

De repente, chega um relatório de bug: "Pânico ao processar lista de usuários". Você abre o código e vê o problema: a referência &mut está sendo usada em vários lugares. Rust não permite que você atire no próprio pé, mas às vezes luta com você pelo direito de posse.

Aqui está o trecho problemático:

fn process_users(users: &mut Vec<User>) {\n    let admin = users.iter_mut().find(|u| u.role == Role::Admin).unwrap();\n    admin.do_task(); // empréstimo mutável\n    // e aqui queremos usar users novamente\n    let count = users.len(); // ERRO! users já foi emprestado\n}

Você corrige separando a lógica:

fn process_users(users: &mut Vec<User>) {\n    // Primeiro encontra o índice, depois trabalha\n    if let Some(admin_idx) = users.iter().position(|u| u.role == Role::Admin) {\n        let admin = &mut users[admin_idx];\n        admin.do_task();\n    }\n    // Agora pode usar users com segurança