O Custo Real de uma Escolha Exótica

É tentador escolher uma linguagem porque é elegante, ou rápida, ou porque alguém que você respeita jura por ela. Especificamente para vibe coding, esse instinto pode afundar um projeto silenciosamente. Eis o motivo: cada hora que você gasta lutando com o ferramental de uma linguagem de nicho, ou desemaranhando saída de IA que está sutilmente errada porque o modelo viu poucos exemplos, é uma hora que você não gastou entregando. A escolha exótica raramente falha alto e claro. Ela falha como um gotejamento lento de loops de correção extras, bibliotecas ausentes e respostas do Stack Overflow que não existem.

Concretamente, a penalidade aparece em três lugares. Primeiro, a IA é menos fluente, então comete mais erros e é pior em corrigi-los — e você, sem conhecer a linguagem, não consegue distinguir código bom de código ruim. Segundo, o ecossistema é mais fino, então a biblioteca de que você precisa pode não existir, pode estar abandonada, ou pode não ter exemplos para copiar. Terceiro, quando você fica travado, a web está mais silenciosa: menos tutoriais, menos perguntas respondidas, menos gente que já bateu na sua parede exata. Com Python ou TypeScript, essas três coisas simplesmente não são um problema.

Nada disso significa que linguagens exóticas são ruins. Significa que o ônus da prova recai sobre a escolha exótica. Se você tem um motivo concreto e específico — você genuinamente precisa da velocidade de Rust, é forçado a usar Swift pela App Store, está estendendo um serviço Go existente — então pague o custo de olhos abertos. Se o motivo é "parecia legal", escolha a opção popular e entregue algo. Você sempre pode reescrever depois, e quase nunca vai fazer isso, porque a escolha popular terá cumprido o trabalho.