Entendendo os tipos de linguagem na prática
A maioria das pessoas confunde categoria de linguagem com sintaxe. São coisas diferentes. Um compilador em C não tem nada a ver com uma linguagem de markup como HTML, mesmo que ambas sejam chamadas de "linguagens de programação". O que define o tipo é o modelo de execução, não a aparência do código. Isso mata muita gente no início porque você gasta meses aprendendo Python e depois tenta aplicar a mesma mentalidade em Rust e quebra tudo.
os tipos de linguagem: classificação real
Se você parar para olhar a literatura técnica sem romantizar, chegam em aproximadamente cinco categorias distintas. Não são subclasses arbitrárias. Cada uma responde a um problema diferente. Linguagens de máquina. Binário puro. 0 e 1. A CPU lê isso diretamente. Ninguém escreve isso manualmente há décadas, exceto talvez em contextos de exploração de zero-days ou embedded extremamente restrito. Mas é o único nível onde o hardware realmente "entende" o que está acontecendo.
Linguagens assembly. Mnemônicos que mapeiam para instruções de máquina. Ainda depende totalmente da arquitetura. Assembly x86_64 não roda em ARM. Você precisa escrever versões separadas. Eu passei duas semanas em 2019 debugando um driver de kernel que tinha um bug só porque converti mal um registrador de 64 bits para 32 bits durante o cross-compilation. O erro não aparecia no emulador. Aparecia só no hardware real, com latency diferente. Linguagens de alto nível. Aqui entram C, Java, Python, Go, Swift. Elas abstrai o hardware. O compilador ou interpretador faz a tradução. O ganho é produtividade. O custo é que você perde controle sobre memória, thread scheduling e muitas vezes performance. Não é ruim. É apenas uma troca. O problema é que desenvolvedores júnior frequentemente não percebem essa troca e ficam surpresos quando o Python deles consome 2GB de RAM num processo que em C faria com 50MB.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Linguagens de script. Python, JavaScript, Lua, PHP, Ruby. São um subconjunto das de alto nível, mas com característica específica: execução interpretada, tipagem dinâmica predominante, e propósito voltado para automação ou integração. A confusão comum é achar que "script" significa "simples". Script em produção mal estruturado é mais perigoso que código compilado mal estruturado porque não tem type checking e o runtime error aparece só quando o usuário clica no botão errado. Linguagens declarativas. SQL, HTML, CSS, Prolog, Haskell (parcialmente). Aqui você descreve o que quer, não como obter. SQL é o exemplo mais óbvio. Você diz quais dados quer. O query optimizer decide o plano de execução. E esse plano pode ser horrível se você não entender índices. Eu vi uma query que levava 4 segundos virar 12 minutos porque alguém adicionou um LIKE com wildcard à esquerda e eliminou o uso de índice. O resultado era o mesmo. O tempo não.
Tem também as linguagens funcionais puras (Haskell, Elm) e linguagens orientadas a objetos (Java, C#, Smalltalk). Mas essa divisão é mais filosófica do que técnica. Você pode fazer POO em linguagens funcionais e vice-versa. O que muda é a convenção, não a capacidade.
Como escolher sem errar
A tentação é escolher pela moda. Linguagem que está em alta no Hacker News não é necessariamente a certa pro seu problema.scolha deve vir de três variáveis: domínio do problema, constraints de performance e ecossistema disponível. Se você tá construindo um scraper que roda uma vez por semana, Python é perfeito. Se você tá construindo um motor de jogo que precisa rodar a 120fps em hardware limitado, Rust ou C++ são as opções reais. Se você precisa de uma API REST que processe 10 mil requisições por segundo com latência previsível, Go ou Rust novamente. Se você precisa de análise estatística pesada, Python com NumPy/PyTorch não tem konkurent no ecossistema atual.
O erro mais comum que eu vejo é gente começando com JavaScript porque "é fácil", depois precisando migrar pra algo mais robusto e perdendo seis meses refatorando. Começar certo economiza tempo. Começar fácil às vezes custa mais caro no longo prazo. O segredo não é dominar todas. É dominar duas profundamente e saber quando usar cada uma. Mais do que três linguagens diferentes e você começa a confundir padrões de design entre elas, o que gera código que parece certo mas tem bugs sutis de semântica.
