Windows, Linux ou macOS para programar

Toda discussão de SO para programar vira religião antes de chegar a um argumento concreto. Um cara defende Linux porque usa Arch e já compilou o kernel uma vez. Outro defende Mac porque tem um MacBook Pro que a empresa pagou. E tem o que usa Windows e não larga porque o Excel funciona sem gambiarras. Nenhum deles está errado — mas nenhum está te dando informação útil.

A resposta honesta é: depende do que você faz. E tem casos onde uma plataforma é claramente melhor. Esse post tenta ser esse argumento concreto.

O que Windows faz bem para programar

Windows melhorou muito com o WSL2 (Windows Subsystem for Linux). Se você roda um kernel Linux dentro do Windows com acesso ao filesystem, toolchain e rede, a diferença prática para desenvolvimento backend ficou menor.

Mas o que Windows ainda é imbatível:

Stack .NET e C#. O ecossistema é primeiro no Windows. Visual Studio (o IDE, não o Code) tem debugging, profiling e integração com Azure que no Linux ou Mac funcionam com limitações. Se você trabalha em empresa que usa .NET Framework legado, nem discute.

Jogos e computação gráfica. DirectX, Unreal Engine, drivers de GPU para workloads de ML com CUDA — tudo roda melhor no Windows. Nvidia tem drivers e ferramentas muito mais maduras para Windows do que para Linux.

Softwares corporativos. Teams sem Electron com comportamento esquisito, Office sem gambiarras de Wine, sistemas de VPN proprietários que o time de TI só sabe configurar em Windows. Se você está num ambiente corporativo conservador, resistir ao Windows custa mais energia do que vale.

O ponto fraco real ainda é o terminal. PowerShell é capaz, mas a ergonomia de bash, pipes Unix e tooling de linha de comando é qualitativamente diferente. WSL2 resolve isso parcialmente, mas você acaba com um sistema dual onde parte das coisas roda no Windows e parte no Linux, e às vezes as fronteiras vazam (performance de I/O entre filesystems, por exemplo).

O que Linux faz bem para programar

Linux é o ambiente onde a maioria dos servidores roda. Isso tem uma implicação óbvia: o que você testa localmente é o que vai rodar em produção. Paridade de ambiente elimina uma categoria inteira de bugs que só aparecem em staging.

Backend e DevOps. Docker sem overhead de VM, cgroups nativos, namespaces, eBPF, ferramentas de observabilidade que assumem Linux. Se você escreve código que vai rodar em Kubernetes ou em qualquer VPS, Linux no desktop é a escolha racional.

Configurabilidade radical. Você escolhe kernel, scheduler, filesystem, compositor gráfico. Isso é trabalho extra no início, mas significa que a máquina faz exatamente o que você precisa, sem processos de telemetria rodando em background, sem updates forçados, sem interface que tentou se reinventar e quebrou o workflow.

Hardware específico. Máquinas com muita RAM (64GB+) para workloads de banco de dados ou compilação pesada ficam mais baratas no hardware de PC genérico do que em Mac. E Linux usa esse hardware sem intermediário.

O custo é suporte a periféricos. Impressoras, scanners, webcams com software próprio, tablets Wacom — às vezes funcionam perfeitamente, às vezes precisam de workaround, às vezes não funcionam. Outro custo é tempo de setup: uma distro bem configurada para desenvolvimento não é uma tarde, é um investimento de alguns dias.

Permissões de arquivo (chmod, chown) são um ponto de atrito constante para quem vem de outros sistemas. Se você ainda está aprendendo a lidar com isso, o Calculador de Chmod ajuda a montar a notação octal sem precisar decorar a tabela toda vez.

O que macOS faz bem para programar

macOS tem a melhor relação entre "funciona sem configurar" e "tem terminal Unix real". Você abre um Mac novo, instala o Xcode Command Line Tools e o Homebrew, e em duas horas tem um ambiente de desenvolvimento funcional para praticamente qualquer stack.

Desenvolvimento mobile iOS e macOS. Xcode só roda em Mac. Não tem discussão aqui. Se você desenvolve para Apple, usa Mac.

Experiência unificada de hardware e software. O Apple Silicon (M1, M2, M3, M4) tem desempenho e eficiência energética que o hardware x86 não alcança ainda. Um MacBook Pro M3 roda builds pesados e ainda passa o dia inteiro na bateria. Para quem trabalha mobile (sem tomada perto), isso muda a realidade.

Ferramentas de design e criatividade. Figma, Sketch, Framer, Final Cut, Logic — o ecossistema de ferramentas para produto e design é mais maduro no Mac. Times de produto onde devs e designers dividem ferramentas tendem a convergir para Mac.

O ponto fraco é custo e controle. Um Mac barato tem limitações de RAM e storage que incomodam em workloads pesados (banco local, muitas abas de browser, Docker com vários serviços). Upgrades são caros ou impossíveis. E a Apple toma decisões de plataforma que você não pode reverter — Gatekeeper, sandboxing, depreciação de drivers.

Outro ponto real: o ecossistema de containers no macOS ainda tem overhead. Docker Desktop roda sobre uma VM Linux. Para a maioria dos usos isso é transparente, mas em I/O intensivo você sente.

Como escolher por stack

Em vez de escolher por sistema operacional favorito, escolha por onde sua stack vive:

Dual boot e VMs mudam o cálculo?

Parcialmente. WSL2 no Windows e UTM/Parallels no Mac aproximam os sistemas, mas não zeram as diferenças.

WSL2 tem I/O lento entre o filesystem Linux e o Windows (/mnt/c é mais lento que o filesystem nativo do WSL). Para projetos que ficam 100% dentro do WSL, funciona bem. Mas tooling que assume Windows (IDEs com integração nativa, VPNs corporativas) não enxerga o WSL sem configuração extra.

Virtualização no Mac tem overhead em I/O e memória. Um container que usa 512MB no Linux vai usar mais no Mac por causa da VM intermediária. Para a maioria dos projetos é irrelevante, mas para workloads de banco de dados ou streaming de dados, o overhead aparece.

Perguntas frequentes

Posso programar em Windows sem WSL?

Sim, para a maioria das stacks. Node.js, Python, Go, Java têm builds nativos para Windows. O que muda é o tooling de linha de comando — shells, utilitários Unix, scripts bash. Se você não usa shell scripts e usa IDEs com terminal integrado (VS Code, IntelliJ), a diferença prática é pequena. O WSL2 é recomendado quando você precisa de paridade com ambiente Linux de produção.

Linux é difícil para iniciantes?

Depende da distro e do uso. Ubuntu com interface GNOME é mais amigável do que Linux tinha reputação de ser. O atrito real aparece quando algo quebra — driver de GPU, configuração de hibernate, VPN corporativa — e você precisa debugar via terminal. Para programadores, esse nível de exposição ao sistema é frequentemente útil. Para não-programadores, pode ser frustrante.

Vale comprar Mac só para programar?

Depende do orçamento e da stack. Se você programa para iOS, sim, é obrigatório. Para backend geral, o custo-benefício depende do quanto você valoriza a experiência integrada versus o custo. Um PC com Linux de preço equivalente tem mais RAM e storage. A diferença de produtividade, sendo honesto, é real mas não dramática — a menos que você programe em movimento e a bateria seja um fator crítico.

Qual SO o mercado de trabalho espera?

A maioria das empresas de produto usa Mac (padrão de mercado no Brasil e nos EUA para dev). Empresas corporativas grandes usam Windows. Startups de infraestrutura e DevOps tendem a Linux ou Mac. Nenhum SO vai te tirar de uma vaga se você for bom — mas ter Mac pode facilitar onboarding em algumas empresas que não têm processo para configurar ambiente em Windows.

O SO não é o gargalo

Depois de anos vendo devs trocando de SO esperando ganhar produtividade, o padrão que observo é o seguinte: quem é produtivo é produtivo em qualquer ambiente depois de algumas semanas de adaptação. Quem luta com produtividade vai lutar em qualquer SO.

O que vale a pena otimizar é o ambiente dentro do SO: shell configurado, atalhos de teclado, gerenciador de janelas que funciona do jeito que você pensa, ferramentas de linha de comando que você conhece bem. Isso importa mais do que a escolha da plataforma.

Se você está começando: use o que a empresa ou o curso usa. Se você está escolhendo por conta própria: use Linux se você faz backend/DevOps e quer o ambiente mais próximo de produção. Use Mac se você quer o menor atrito entre setup e trabalho. Use Windows se a sua stack é .NET, jogos, ou você está num ambiente corporativo com pouco suporte para outras plataformas.