Quais são as suas ferramentas de desenvolvimento favoritas?

 (lobste.rs)
33 pontos por GN⁺ 12 시간 전 | 8 comentários | Compartilhar no WhatsApp
  • Na área de editores, Helix, Emacs, Neovim, Sublime Text, Zed e as IDEs da JetBrains aparecem repetidamente, com os trade-offs de cada um ficando bem claros
  • Em controle de versão, destaca-se a tendência de jujutsu(jj) substituir a CLI do git, com várias menções também a ferramentas auxiliares com GUI como Magit, lazygit e Sublime Merge
  • Em shell, terminal e gerenciamento de ambiente, Fish, WezTerm, Ghostty, kitty, tmux, Nix, mise, atuin e fzf surgem como a stack principal
  • A mensagem recorrente é: "escolha ferramentas com bons padrões e evite configurações intermináveis" e "com a idade, em vez de moldar a ferramenta a você, adapte-se a bons padrões" (embora também haja opiniões contrárias)

Contexto da discussão

  • Thread no Lobsters com a pergunta "Qual é a ferramenta favorita dos desenvolvedores?" e a observação de que "desenvolvedores têm opiniões fortes, então é difícil apontar uma única ferramenta"
  • Mais de 130 comentários em apenas 19 horas
  • Filosofia que apareceu repetidamente: "com a idade, em vez de moldar a ferramenta a mim, ajusto minhas preferências a ferramentas com bons padrões", porque assim "você fica no caminho mais testado e encontra menos bugs"
    • Opinião contrária: "com a idade, a paciência com padrões ruins diminui. Se eu não conseguir deixar a ferramenta utilizável em poucos minutos, troco por outra"

Editor de texto / IDE

  • Helix

    • "o ponto de equilíbrio certo entre possibilidade de customização e ótima experiência padrão"
    • Ao usar com jujutsu, após trocar de commit é preciso recarregar manualmente os arquivos abertos — uma solução temporária é usar um atalho para :reload-all
    • Um PR de monitoramento de arquivos (#14544) está em andamento por um maintainer
    • Também há muitos casos de gente que não conseguiu se adaptar ao modelo selection-first e voltou para o vim
    • Fork com suporte parcial a keybindings do vim: evil-helix

  • Emacs

    • Muitos usuários responderam simplesmente "Emacs"
    • Magit recebeu elogios suficientes para ser citado à parte
    • Fluxo de migração por área: Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org-mode, Finder → dired

  • Neovim

    • "Aposentei meu .vimrc de mais de 10 anos e migrei de vez para o Neovim"
    • Ecossistema de distribuições de plugins:
      • LazyVim: a mais completa; recomendam desativar os atalhos do flash.nvim
      • AstroNvim: alternativa mais enxuta
      • Kickstart.nvim: ponto de partida simples e voltado à customização
      • MiniMax: config inicial feita pelo time do mini.nvim

  • IDEs da JetBrains

    • Forte recomendação para o depurador do PyCharm — funciona até dentro do REPL do Django, suporta HTML/CSS/JS em templates e permite cherry-pick por hunk
    • Se você usa 2 ou mais produtos da JetBrains, a licença All Products sai mais barata

  • Sublime Text / Zed

    • "Sublime Text é subestimado", com respostas dizendo que o usam diariamente há mais de 20 anos
    • Mesmo codando em outro lugar, o alto desempenho e os buffers não salvos persistentes fazem dele uma ferramenta de uso diário
    • Também surgiu a tendência de migrar para o Zed porque o VSCode ficou pesado demais

  • Kate / Notepad++

    • Kate no mundo Linux e Notepad++ no mundo Windows também foram citados de forma direta

Controle de versão

  • jujutsu (jj) — a ferramenta mais mencionada do ano

    • "Eu não imaginava que abandonaria a CLI do git, mas foi exatamente o que aconteceu"
    • "É raro uma ferramenta ser ao mesmo tempo mais fácil e mais poderosa, e o jujutsu consegue ser os dois"
    • Há elogios ao fato de rebase e commit amend terem ficado prazerosos
    • Ponto fraco: os padrões ainda não estão refinados, exigindo ajuste de cores/templates — o padrão foi descrito como "texto de vômito de unicórnio arco-íris em alto contraste"

  • Ferramentas auxiliares para Git

    • tig: "uma versão melhorada do git log", usada também para staging interativo
    • Magit: peça central para usuários de Emacs
    • Sublime Merge: "uma camada GUI sobre o git, mas extremamente bem feita"; também pode integrar com jj usando merge-editor = "smerge"
    • lazygit: faz as pessoas tentarem com mais frequência tarefas complexas como rebase, revert, stash e múltiplos remotes
    • delta: quando configurado como pager do git, fornece diff com syntax highlighting; combinado com lazygit, permite alternar entre side-by-side e inline
    • difftastic: diff baseado em sintaxe, não em linha
    • git revise: "deveria vir no git por padrão"
    • Beyond Compare: ferramenta de diff/merge/sincronização de pastas usada há 20 anos

Shell / terminal

  • Fish

    • "faz tudo que bash e zsh fazem, mas oferece uma experiência excelente sem praticamente nenhuma configuração"
    • Quando necessário, scripts bash continuam podendo ser executados normalmente
    • É visto como uma ferramenta na qual você continua descobrindo novos atalhos (por exemplo, alt+<left|right> para histórico de diretórios)

  • Emuladores de terminal

    • WezTerm: copiar/colar só com o teclado (ctrl+shift+space), duplicação de aba no mesmo sistema com ctrl+shift+t, cliente SSH e multiplexador integrados
    • Ghostty: integração nativa com macOS — popover de dicionário com Cmd+Ctrl+D, drag-and-drop, abas nativas e qualidade de renderização de fontes
    • kitty: "exemplo de boa ferramenta em que os padrões simplesmente funcionam e, ao mesmo tempo, há bastante espaço para configuração"

  • tmux

    • o primeiro comando executado ao abrir uma sessão de terminal
    • Protege contra desconexão de SSH ou fechamento acidental do terminal — e permite manter o mesmo padrão alternando entre Mac e NixOS

  • Starship

    • Pode ser plugado em qualquer shell, mas em repositórios grandes os comandos git status/branch ficam lentos

Gerenciamento de ambiente / dependências

  • Nix / NixOS

    • "Pode até ser síndrome de Estocolmo, mas faz com que você não consiga mais usar outras distribuições Linux e sistemas de build"
    • Com nix shell por projeto, dá para minimizar pacotes do sistema e fixar versões exatas sem poluir o PATH global
    • "Alta confiança de que continuará funcionando do mesmo jeito daqui a 1 ano ou 5 anos"
    • "Depois de vencer a curva de aprendizado, parece mágica. Era assim que a configuração do SO deveria ser"

  • mise

    • Gerenciador de versões de ferramentas que substitui o direnv, com integração até em CI leve
    • "um substituto estritamente melhor para o asdf"
    • Ao descobrir a função mise activate, dá para remover o direnv por completo
    • Com mise watch e o sistema de tasks, permite ações por projeto e execução de tarefas com base em mudança de arquivos

  • Dev Containers

    • A vantagem é poder compartilhar o ambiente de deploy docker/container com o ambiente de desenvolvimento
    • Desvantagem: o tooling ainda é imaturo (a CLI de referência nem implementa comando de stop)

  • chezmoi

    • Mantém um ambiente de desenvolvimento consistente entre máquinas de trabalho e pessoais, gerenciando juntos aliases de git, config do Neovim, access tokens e instalação de outras ferramentas

Depuração / profiling

  • rr — depurador de gravação/replay

    • "ferramenta principal para depuração em C/C++, onde você grava uma vez e depois reproduz infinitamente de forma determinística"
    • Permite observar endereços de memória e voltar até a última escrita
    • "temporal debugging bisection" — com watchpoints, dá para navegar para frente e para trás até encontrar o ponto exato da corrupção de memória

  • Pernosco

    • Depurador com time-travel + análise de fluxo de dados
    • Foi decisivo em trabalhos com focus handling de múltiplos content processes do Firefox e compatibilidade do Chrome com about:blank

  • RenderDoc / Tracy / RemedyBG

    • RenderDoc: ferramenta coringa para depuração gráfica, com recursos básicos melhores que o depurador Metal do XCode
    • Tracy: "se você criasse um profiler com recursos ilimitados, o resultado seria o Tracy"
    • RemedyBG: depurador elogiado pela boa ergonomia de trabalho

  • XCode Instruments

    • Em profiling de shaders 3D/GPU, fornece anotações do custo de execução por linha
    • Ajuda a analisar a causa de stalls — espera por fetch de memória, sincronização ou divergência de fluxo de controle
    • "a vantagem de um ecossistema que controla hardware, driver, linguagem de shading Metal e tooling ao mesmo tempo"

  • Outros

    • strace, extrace, perf — combinação essencial para depuração
    • gdb — ainda muito citado de forma direta

Busca / processamento de texto

  • fzf: integração com busca reversa do shell, com "o grau certo de fuzzy"
    • Com o padrão rg '' | fzf, faz busca textual no repositório inteiro; ao selecionar um match, retorna imediatamente ao prompt algo como vim foo.rs +123
  • ripgrep: "funciona corretamente out of the box, nunca nem tentei configurar"
  • septum: busca interativa de código — consultas condicionais como "conter triangle, vertex e mesh em até 7 linhas, mas excluir physics"
  • fastmod / spacemod: substituições em massa
  • autojump: com j whatevs, vai para diretórios usados no passado por fuzzy matching
  • zoxide: semelhante ao autojump, com navegação mais fluida
  • awk: continua forte para tarefas de "extrair só um pouco e ajustar só um pouco"
  • entr: "observe estes arquivos e execute isto" — ótimo para rodar testes automaticamente em um codebase

JSON / dados / ferramentas de conversão

  • jq: padrão de fato para processar JSON; há recomendação de ler o manual inteiro, além do jq track do Exercism
    • gojq: mensagens de erro muito superiores às do jq nativo, além de suporte a entrada YAML, o que permite reaproveitar a mesma muscle memory
  • fx: exploração detalhada de saídas JSON grandes
  • hexdump: especialmente hexdump -C, útil para depuração embarcada — padrão como picocom --baud 115200 /dev/ttyUSB | hexdump -C
  • hexyl: visualizador hexadecimal com cores
  • bat: substituto do cat com syntax highlighting
  • choose, fd: substitutos de cut e find, respectivamente

Histórico do shell / clipboard / notas

  • Atuin: sincronização do histórico do shell e busca com base no contexto do diretório ou repositório git
  • CopyQ: gerenciador de clipboard com cerca de 2000 itens, útil para recuperar trabalho antigo quando alguma anotação se perde
  • histprune: customização do Ctrl+R do fzf — com alt+D, apaga imediatamente itens do histórico
  • Obsidian: migração vinda do Logseq; guardar tudo em Markdown puro favorece a colaboração com LLMs/agentes
  • Joplin: AGPLv3, com suporte a apps desktop, mobile e web, backend WebDAV/OneDrive/S3 e armazenamento direto em arquivos .md

Build / automação de tarefas

  • just: substituto do make — focado em tasks, não em build, e oferece uma interface consistente como just lint independente da linguagem
    • "permite alternar por target entre o modo linha a linha do make e o modo script completo em shell/python/node"
    • Desvantagens: grava scripts embutidos em $TMPDIR antes de executar e usa uma linguagem de template própria (uncanny valley)
  • Task (go-task): alternativa baseada em yaml, com perfil batteries-included
  • universal-test-runner: detecta automaticamente como executar os testes do repositório e repassa argumentos adicionais
  • chezmoi: também usado para gerenciar com consistência dotfiles e instalação de ferramentas entre máquinas

HTTP / rede / segredos

  • Hurl: "esqueça os apps GUI de HTTP que tentam coletar informações" — formato de texto simples para requisições curl, adequado para testes integrados
  • curl: muito citado de forma direta
  • SOPS: criptografia de segredos com chave age/SSH, no padrão sops exec-env secrets.yaml -- some command
  • Mutagen: sincronização bidirecional de arquivos em tempo real sobre SSH — útil para trabalhar em máquinas remotas
  • forge: substituto para a GitHub CLI, com suporte a Codeberg e uma experiência mais rápida e organizada

Outros / fluxo de trabalho

  • Quarto: apresentações rápidas em markdown
  • Nushell: shell influenciado pelo PowerShell, usado para escrever de forma confiável scripts de transformação em larga escala, como GeoPackage → PostGIS e views PostGIS → PMTiles. Desvantagem: por ainda estar antes do 1.0, quebra a cada atualização
  • Typst: citado como alternativa ao LaTeX, com preferência por sua sintaxe baseada em call-by-value
  • Topiary: formatador multilíngue
  • Hunk: visualizador de diff em terminal com review-first para agentic coders, com uso do modo --watch ao lado de agentes de programação
  • Raycast / Alfred: launchers para macOS, com snippets, clipboard e buscas web parametrizadas
  • Ergodox EZ: teclado usado há 10 anos, aprovado em customização e energia
  • Joplin / Fossil: auto-hospedagem de notas e wiki
  • AeroSpace / Sway: gerenciadores de janelas em mosaico

Mensagens meta recorrentes

  • "Escolha ferramentas com bons padrões e evite configurações intermináveis" — Helix, Fish, ripgrep e mise são citados como exemplos representativos dessa filosofia
  • Visão oposta: também existem casos de pessoas que, após infinitos ajustes, construíram seu próprio sistema ideal de ferramentas — "agora só mexo algumas vezes por ano"
  • Subproduto da era dos agentes de IA: cresce a percepção de que jq, Markdown e ferramentas de texto estruturado favorecem a colaboração com LLMs — o Markdown puro do Obsidian, o modo watch do hunk e a recomendação de estudar o manual do jq seguem a mesma linha
  • Vantagem do macOS em depuração gráfica: avaliação de que o profiling de GPU no XCode Instruments é muito superior ao do Linux/Windows
  • Renascença da CLI vs tipografia: ao mesmo tempo em que as ferramentas de terminal florescem, observa-se que saídas longas de LLMs/agentes acabam sendo mais agradáveis de ler em navegadores ou apps dedicados, por causa da tipografia

Leituras relacionadas

8 comentários

 
kirinonakar 24 분 전

Usei alguns, mas nenhum me agradou de verdade, então estou criando o meu próprio. Estou me baseando no notepad++, VS Code, Zed e Obsidian, pegando só os recursos de que preciso.
 
xguru 10 시간 전

Tenho usado bastante os três em conjunto ultimamente: cmux, tmux e mux.
Quando faço login via ssh em um servidor conectado pelo Tailscale, uso o fzf para listar em conjunto as sessões existentes do tmux e, a partir dali, escolho em qual entrar.

cmux - Terminal para macOS baseado em Ghostty para agentes de programação com IA
Show GN: mux – gerenciador de sessões tmux que transforma sessões de programação com IA em prévias ao vivo
 
edunga1 2 시간 전

No Mac, para digitar em coreano no terminal, não precisa apertar Enter duas vezes? (duas vezes: uma para concluir a composição em coreano e outra para inserir)
O único que não tinha esse problema era o wezterm, então acabei migrando para ele.
 
onixboox 3 시간 전

Gosto do Zed
 
snisty 5 시간 전

Agora eu virei o tipo de pessoa que não consegue mais viver sem o Claude Code. + tmux..
E, acrescentando, o VSCode como editor de texto..
Fora isso, só o IDE essencial, tipo o Visual Studio para build..
 
hwhang0917 8 시간 전

fzf, jq, rg, awk ❤️
 
jjpark78 10 시간 전

neovim, alacritty, tmux, fzf, rg, obsidian, bat, jq, hurl, lazygit, hammerspoon, chrome, codex, claude,
 
GN⁺ 12 시간 전
Opiniões do Lobste.rs

  • Uso Helix como editor de texto. Para mim, ele acerta em cheio no equilíbrio entre possibilidade de personalização e uma ótima experiência padrão
    Pelo mesmo motivo, uso Fish como shell de terminal. O padrão dele é excelente, e quase não preciso ajustar nada para usar do jeito que quero
    Conforme fui ficando mais velho, passei a preferir adaptar meu gosto a ferramentas com bons padrões intencionais, em vez de ficar mexendo em configuração sem parar
    Atuin é ótimo para sincronizar o histórico do shell entre máquinas remotas e para buscar o histórico de forma contextual, com base no diretório atual ou no repositório git. Tem outros recursos, mas eu só uso esses
    Também gosto bastante do Mise por vários motivos, mas principalmente como gerenciador de versões de ferramentas. Ele substituiu o direnv que eu usava antes, e em projetos pessoais comecei a integrá-lo aos poucos em fluxos leves de CI

    • O caminho dos bons padrões é o mais testado, então você encontra menos bugs. Em geral, é uma escolha sensata
    • Não existe só “adaptar seu gosto aos padrões” e “ficar mexendo em configuração sem parar”. Na minha experiência n=1, eu fui mexendo, mexendo e mexendo até chegar onde queria, e agora quase não mexo mais
      Só algumas vezes por ano. Meu Emacs virou uma espécie de caixa de ferramentas Studley pessoal
    • Eu queria gostar de Helix. É um projeto muito polido e os padrões são atraentes, mas tenho memória muscular de Vim demais acumulada
      Em vez disso, alguns meses atrás abracei o Neovim de vez e aposentei meu .vimrc que cresceu organicamente por mais de 10 anos. Deu um pouco de pena, mas agora invejo menos o Helix
      O Mise também é bom e, na prática, quase não exige configuração. Também comecei a usar Fish há alguns meses e, tirando algumas funções de usuário, deixo quase tudo no padrão
      Ripgrep também simplesmente faz “a coisa certa” no estado padrão, a ponto de eu nem saber se já tentei configurá-lo alguma vez
    • Qual é a melhor forma de aprender a usar Helix de verdade? Estou tentando sair do Neovim porque me preocupa demais a cadeia de suprimentos, já que a estrutura de plugins puxa mais de 50 repositórios
    • Eu me identifico muito com isso. Conforme fui envelhecendo, entendo cada vez menos as pessoas que mexem tanto assim em ferramentas e software. Não é divertido e não vale a pena

  • Emacs

  • Talvez seja síndrome de Estocolmo, mas é Nix. Não é perfeito, mas depois que passei a trabalhar de forma mais expressiva e eficiente com Nix, ele praticamente estragou as outras distribuições Linux e sistemas meta-build para mim
    E, já que estamos nisso, pwntools também é uma ferramenta divertida de usar fora de CTF. Por exemplo, para mexer com sockets bit a bit a partir de um REPL Python

    • Gosto tanto de Nix quanto de pwntools. Como colega de CTF, fiquei curioso: se você tem um ambiente de pwn para CTF baseado em Nix, queria saber como montou isso
      Eu sempre subi uma VM Ubuntu nova no libvirt e colocava as ferramentas lá para trabalhar, mas você teria alguma recomendação de abordagem baseada em Nix?

  • Emacs, claro, e especialmente Magit

  • Nix. Tem curva de aprendizado. Passei alguns anos convivendo com usuários e evangelistas de Nix antes de tentar seriamente, mas no fim é muito bom
    Conforme fui trabalhando em vários projetos, cansei de ter ferramentas diferentes para gerenciar dependências em nível de sistema. Uma para versão de Node, outra para versão de Python, e por aí vai
    Também me cansei de falhas de build difíceis de depurar por incompatibilidades entre projetos. O $foo quebrava no Projeto A, eu atualizava via Homebrew, e aí o $foo quebrava no Projeto B
    E também é cansativo quando o processo de build depende de várias dependências instaladas no sistema, muitas vezes ocultas, então o build falha “por algum motivo”
    Levei tudo o que pude para nix shell por projeto. Mantenho os pacotes em nível de sistema o mais enxutos possível e, nos projetos, fixo exatamente as versões das ferramentas necessárias: dependências, runtimes, compiladores etc.
    Isso não polui meu PATH global nem outros projetos. Se funciona para mim agora, tenho bastante confiança de que vai funcionar daqui a 1 ano ou 5 anos
    Quando quero atualizar ferramentas, também posso fazer isso sem me preocupar em afetar outros projetos e, se surgir regressão, é fácil voltar atrás ou fixar só uma dependência em uma versão anterior
    Também é melhor nos projetos em que meus colegas usam Nix. O tempo extra para configurar e manter o nix shell é compartilhado, e a confiança de que o ambiente de desenvolvimento é igual para todos aumenta bastante

    • Por motivos parecidos, ultimamente tenho gostado muito de Dev Containers. Acho a ideia muito boa, mas infelizmente a qualidade das ferramentas ainda não acompanha
      Por exemplo, nem mesmo a CLI de referência implementa o comando stop ainda. Mesmo assim, se você usa Docker/contêineres em produção, há a vantagem de poder compartilhar bastante configuração entre o ambiente de desenvolvimento e o de implantação
      https://containers.dev/
      https://github.com/devcontainers/cli

  • rr(https://rr-project.org/) é um software tão magicamente bom que eu quase não conseguiria viver sem

    • Antigamente, teria sido uma ferramenta de uso diário para mim. Ótima descoberta. Vou colocá-la no meu second brain para conseguir achar depois quando voltar a precisar
    • Fiquei curioso: onde você extrai mais valor do rr? Entendo a explicação geral da página inicial do projeto
      A ideia de registrar uma falha uma vez e depois depurá-la de forma determinística quantas vezes quiser claramente parece útil
      Mas estou perguntando pela experiência prática porque ainda não tive muito aquela sensação de “uau, esse bug/fluxo de trabalho específico teria sido impossível de resolver sem rr”

  • Venho de background de administração de sistemas, então estou muito mais para “usar bons padrões com o mínimo de configuração”. Mas duas coisas recentes acabaram quebrando esse hábito
    jujutsu(jj) já foi bastante comentado neste site, mas sinceramente é muito gostoso de usar. Eu não achava que largaria a CLI do git, mas foi o que aconteceu
    Passei anos evitando aprender a usar e configurar nvim, mas nvchad me deu um ponto de partida. O nome é terrível, mas para mim é uma ótima configuração inicial: exatamente opinativa o bastante sem deixar de ser minimalista
    Claro que agora já uso desde o começo minha própria configuração mínima
    Fora isso, como uso bastante Python, também tenho que dizer que é consistentemente prazeroso usar as ferramentas da astral. Espero que a Anthropic cuide bem delas

    • jujutsu é duas vezes isso. Primeiro porque fazer a transição em si já é bom, e depois porque os padrões do jj ainda não são tão lapidados, então você acaba mexendo mais uma vez
      A menos que você goste daquele texto típico de arco-íris de unicórnio vomitado em alto contraste sobre fundo escuro, dá bastante trabalho ajustar cores e templates

  • Na verdade é Emacs. Aos poucos fui migrando minhas tarefas de computação para o Emacs e comecei a aceitar os padrões
    O Emacs é realmente fácil de personalizar, e muitos atalhos fazem a coisa certa em todos os modos
    A lista da minha migração lenta é Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org mode, Finder → dired
    Quarto também é bem bom para montar apresentações rapidamente em Markdown. Uso Nix e nix-darwin em todos os meus dotfiles

    • Para o caso de uso de dired, vale a pena dar uma olhada no Dirvish

  • Emacs. Não uso com frequência, mas escrever parsers com ragel é divertido

  • Sublime Text com certeza é subestimado por gente demais

    • Eu queria gostar de Sublime Text, mas o modo vi não batia o suficiente com a memória muscular que acumulei no Vim, então não consegui me fixar nele
      Acho que talvez se chamasse algo como “vintage”. Hoje em dia, no tipo de situação em que eu gostaria de ter gostado de Sublime Text, eu uso Zed