Discord nativo em Rust com 30 MB de RAM: como é possível?
O Litecord é um cliente de Discord nativo em Rust que usa 28-35 MB de RAM em idle, contra 400-750 MB do cliente oficial baseado em Electron. Entenda como isso é possível.
Se você joga no PC com o Discord aberto em segundo plano, já deve ter notado: o cliente oficial não é exatamente leve. Em idle, ele ocupa facilmente entre 400 e 750 MB de RAM. Com uma call de voz ativa, esse número sobe para 600 a 900 MB. Nos momentos em que o sistema está mais carregado, durante uma partida pesada, os picos de CPU gerados pelo Discord chegam a causar micro-stutters perceptíveis.
O motivo é estrutural: o Discord desktop é construído sobre o Electron, uma tecnologia que empacota um navegador Chromium completo junto com o Node.js dentro de cada aplicativo. Abrir o Discord é, em termos práticos, equivalente a abrir uma aba do Chrome que roda uma aplicação web local. O Chromium traz tudo que você esperaria de um navegador moderno: motor de renderização, motor de JavaScript, gerenciamento de abas, caches de memória e uma camada de abstração que separa o código da aplicação do hardware.
Essa abstração tem um custo.
Um desenvolvedor brasileiro chamado Ak4ai decidiu medir exatamente quanto esse custo pesa e construir uma alternativa do zero. O resultado é o Litecord, um cliente de Discord nativo em Rust, 100% open source, que consome entre 28 e 35 MB de RAM em idle e inicializa em menos de 200 milissegundos.
Por que o Electron pesa tanto
Para entender o que o Litecord fez diferente, é necessário entender o modelo do Electron.
Quando você escreve uma aplicação Electron, você está basicamente criando um site e colocando um navegador em volta dele. O Electron cuida de tudo: renderização de interface via HTML/CSS, lógica via JavaScript/Node.js, comunicação com o sistema operacional via APIs abstraídas.
Isso é ótimo para velocidade de desenvolvimento. Um time que já sabe fazer aplicações web pode criar um app desktop sem aprender uma nova linguagem ou toolkit de interface. É por isso que o Electron virou padrão na indústria: Discord, Slack, VS Code, Figma desktop e dezenas de outros produtos populares são Electron.
O problema é que o Chromium não foi projetado para ser leve. Ele foi projetado para ser rápido, seguro e compatível com a web inteira. Ele carrega todo esse aparato mesmo quando o seu aplicativo não precisa de 99% dos recursos de um navegador de uso geral.
A stack do Litecord: cada escolha tem uma razão
O projeto do Ak4ai se chama Litecord e foi publicado no TabNews e no GitHub com a stack completa documentada. As escolhas de tecnologia são diretas e cada uma resolve um problema específico.
Rust 2021 Edition
Rust é uma linguagem de programação de sistemas que compila direto para código de máquina, sem precisar de uma máquina virtual ou interpretador em tempo de execução. Ela não tem garbage collector: o gerenciamento de memória é feito em tempo de compilação pelo sistema de ownership, que garante que memória seja alocada e liberada de forma previsível, sem pausas.
Para uma aplicação de comunicação em tempo real como o Discord, isso significa que o pipeline de áudio pode rodar com latência constante, sem as pausas intermitentes que um garbage collector introduz quando entra em ação para limpar memória não utilizada.
Slint UI
A primeira tentação ao escrever um app Rust para desktop seria usar o Tauri, que é um framework popular que substitui o Chromium pelo WebView nativo do sistema operacional. Seria uma melhora em relação ao Electron, mas ainda renderizaria HTML e CSS.
O Litecord foi um passo além e escolheu o Slint UI, um framework de interface declarativa que compila o layout diretamente para instruções gráficas nativas, via FemtoVG com backend OpenGL ou renderizador de software como fallback. A interface não é uma página web: é um conjunto de primitivas gráficas desenhadas diretamente na GPU. O resultado é menos de 10 MB de pegada de memória para a interface inteira.
Pipeline de áudio: CPAL + Opus
Para as chamadas de voz, o Litecord usa a CPAL (Cross-Platform Audio Library), uma biblioteca Rust que acessa a API de áudio nativa de cada sistema operacional, e o decodificador Opus em 48 kHz.
Um detalhe técnico importante: para garantir que a voz não "quebrasse" ou ficasse robótica durante partidas com CPU a 100%, o projeto implementa Opus PLC (Packet Loss Concealment) com um jitter buffer adaptativo de 40 ms e um resampler cúbico Hermite a 48 kHz. Em outras palavras, quando pacotes de áudio chegam atrasados ou se perdem na rede, o algoritmo reconstrói a voz de forma convincente em vez de deixar o áudio recortar.
Tokio para concorrência
O Tokio é o runtime assíncrono mais usado no ecossistema Rust. Ele permite que a aplicação gerencie múltiplas tarefas simultâneas: receber mensagens via WebSocket da API do Discord, fazer chamadas REST, processar áudio e atualizar a interface, tudo sem bloquear a thread principal que mantém a interface responsiva.
A tabela de comparação real
Os números abaixo são os apresentados pelo próprio desenvolvedor, medidos durante o funcionamento do cliente:
| Métrica | Discord Oficial (Electron) | Litecord (Rust Nativo) |
|---|---|---|
| CPU em idle | 1,5% a 4,5% | menos de 0,1% (DeepSleep: 0,0%) |
| CPU com voz ativa | 4,0% a 8,0% | 0,4% a 0,8% |
| RAM em idle | 400 MB a 750 MB | 28 MB a 35 MB |
| RAM com voz ativa | 600 MB a 900 MB | 32 MB a 45 MB |
| Tamanho do executável | ~180 MB | ~8 MB |
| Tempo de inicialização | 4 a 9 segundos | menos de 200 milissegundos |
As funcionalidades mais interessantes
Além das métricas de performance, o Litecord implementou algumas funcionalidades que vão além do básico:
Login por QR Code via Remote Auth v2
Em vez de exigir que o usuário cole tokens de sessão manualmente (o que exigiria inspecionar cabeçalhos de rede), o Litecord implementa o protocolo Remote Auth v2 do Discord via WebSocket com pares de chaves RSA-2048. O login funciona exatamente como no cliente oficial: você escaneia o QR Code com o aplicativo do celular e autoriza com um toque. O token de sessão é armazenado criptografado via Windows DPAPI no Windows.
DeepSleep na bandeja do sistema
Quando o Litecord é minimizado para a bandeja do sistema, todos os loops de renderização e atualizações de interface são completamente suspensos. O uso de CPU cai para exatamente 0,0%. Apenas a thread leve de recepção de áudio RTP/Opus continua ativa, para que você continue ouvindo a call mesmo com o cliente minimizado.
Prioridade de fala para calls táticas
Para quem usa o Discord em jogos competitivos com chamadas de voz em equipe, o Litecord tem um sistema de prioridade de fala. Quando o jogador marcado como líder ou shot-caller fala, o volume dos outros participantes e de eventuais bots de música é atenuado automaticamente (ducking), voltando ao normal quando ele termina. A ideia é resolver o problema clássico de tentar coordenar a equipe enquanto música ou outros áudios concorrem pela atenção.
O que falta e os riscos de usar clientes alternativos
O Litecord é um projeto em desenvolvimento ativo e algumas limitações são esperadas:
Compartilhamento de tela: a implementação ainda está em fase de refinamento, com potenciais pontos de segurança que um usuário da comunidade reportou ao desenvolvedor de forma privada.
Termos de Serviço do Discord: o uso de qualquer cliente não oficial pode, tecnicamente, violar os termos do Discord. Na prática, a empresa raramente bane usuários por isso, mas é um risco real que precisa ser mencionado.
Suporte a plugins: o Litecord não tem suporte a sistemas de plugins como BetterDiscord ou Vencord.
Compatibilidade: um usuário testando em máquina virtual relatou necessidade de instalar o Visual C++ Runtime manualmente no Windows, e problemas com o backend gráfico OpenGL em ambientes sem aceleração de hardware. Em desktop com drivers normais, o projeto não reporta esses problemas.
Por que isso importa além do Discord
O Litecord é interessante como projeto técnico, mas o que ele representa vai além de uma alternativa ao Discord.
O Electron se tornou o padrão de fato para aplicações desktop multiplataforma, e existe uma discussão crescente sobre o custo dessa escolha. VS Code, o editor de código mais popular do mundo, é Electron. Slack é Electron. Figma desktop é Electron. Cada uma dessas aplicações carrega um Chromium inteiro na memória.
Em um computador moderno com 16 GB de RAM, 500 MB por aplicativo é desconfortável mas gerenciável. Em máquinas mais antigas, em sistemas com menos memória disponível ou em contextos onde cada megabyte importa como servidores, contêineres leves ou dispositivos embarcados, o custo é proibitivo.
O Litecord demonstra que é possível construir uma aplicação de comunicação completa, com voz, criptografia e uma interface gráfica decente, em menos de 40 MB de RAM e com um executável de 8 MB. Isso não é apenas uma curiosidade técnica: é um argumento concreto para a conversa sobre as compensações de produtividade de desenvolvimento versus eficiência de recursos que a indústria vai precisar continuar tendo.
Como testar
O Litecord é 100% open source sob licença MIT. O repositório está disponível em:
- GitHub: https://github.com/Ak4ai/Litecord
- Página do projeto: https://ak4ai.github.io/Litecord/
Há executáveis prontos gerados automaticamente pelo GitHub Actions para Windows (instalador .exe e versão portátil .zip) e para Linux (pacote .tar.gz, testado em Ubuntu e Arch).
Se quiser um passo a passo completo de instalação, login por QR Code e configuração, escrevemos um guia dedicado: Litecord: como instalar o Discord nativo em Rust (Linux e Windows).
Fontes
Gosta de ferramentas open source que fazem mais com menos?
No Flateek, cobrimos projetos como esse que mostram o que é possível quando desenvolvedores decidem resolver um problema do zero. Assine nossa newsletter gratuita e receba os próximos artigos diretamente no seu e-mail.
