Conclusões principais
- A linguagem Go nem sempre é mais rápida. Na verdade, um runtime JS pode até ser mais rápido.
- Go se destaca pela simplicidade e eficiência, mas em ambientes reais às vezes pode ter um desempenho abaixo do esperado.
- Especialmente em cenários com muito I/O de banco de dados, pode ter desempenho inferior ao de runtimes JavaScript como o Bun.
Resultados do benchmark
- Go apresentou maior throughput de requisições e menor uso de memória, mas o uso de CPU foi de 2 a 3 vezes maior.
- Porém, em ambientes reais com muito I/O de DB, o Bun (com a combinação do framework Elysia e da biblioteca MySQL2) mostrou desempenho mais estável e eficiente.
- O roteador HTTP padrão teve desempenho baixo, e após migrar para o framework Fiber foi possível obter uma velocidade de resposta semelhante à do Bun. (Não usem o roteador HTTP padrão do Go!)
Pontos fortes do Go percebidos durante este benchmark
- Oferecer vários tipos primitivos e segurança de tipos.
- Deploy em binário único: dá para distribuir como um executável simples, eliminando dependências de runtime.
- Goroutines: suportam processamento paralelo com eficiência e, quando bem usadas, permitem extrair o máximo do hardware.
Limitações e espaço para melhoria percebidos neste benchmark
- Suspeita de problema de desempenho no driver MySQL: o
go-mysql-driver do Go é estável, mas lento, e parece ficar atrás do mysql2 do JavaScript em desempenho. (Claro, também posso estar enganado)
- Em tarefas sem conexão com DB, o Go mostra desempenho melhor. Talvez isso seja até natural.
- Baixo desempenho do roteador HTTP: pelo bem da sua saúde mental, use Fiber ou outro framework!
Por que continuar usando Go mesmo sem ficar satisfeito com o desempenho
- A segurança de tipos do Go, o deploy em binário único e o desempenho de processamento paralelo com goroutines são muito atraentes para quem desenvolve. Tipos que o TypeScript não consegue suprir e a possibilidade de distribuir um único binário sem precisar de
npm install foram vantagens realmente grandes.
- Ao ver que ainda há possibilidade de otimização adicional de desempenho, decidi continuar estudando e usando Go.
Uma mensagem para desenvolvedores
- Toda linguagem e tecnologia tem pontos fortes e fracos. Acho que com Go acontece a mesma coisa.
- Em vez de se decepcionar com o desempenho do Go, vale mais a pena aproveitar bem suas vantagens e continuar buscando meios de superar suas limitações de performance.
- Escrevi este texto para compartilhar com desenvolvedores que usam Go a informação de que esse tipo de análise e resultado também existe.
16 comentários
Totalmente fora do assunto, mas a fonte IBM Plex Sans KR é bonita demais
Eu também gostei muito daquela fonte e cheguei a usá-la, mas há exatamente um ponto decepcionante: em monitores de baixa resolução, ela não fica particularmente bonita. rsrs Em um monitor 5K, fica realmente linda!
Acho que é preciso ter muito cuidado ao criticar algo.
Não está claro se é um problema no nível da linguagem, de uma biblioteca específica ou do próprio código, e afirmar publicamente que algo é ruim sem fornecer informações suficientes para que outras pessoas consigam reproduzir
mesmo que essa não tenha sido a intenção, não parece ser algo agradável para as pessoas que vivem naquele ecossistema.
Olá! Antes de tudo, agradeço por deixar sua valiosa opinião. Entendo com que sentimento você escreveu seu comentário sobre esse ponto e, caso tenha parecido que eu estava criticando o futuro da linguagem Go ou seus usuários, gostaria de dizer mais uma vez que não era essa a intenção e pedir desculpas por isso. E, se estiver tudo bem para você, acho que, ao clicar no título do texto, há vários dados e também um post de blog de outra pessoa, então, se puder ler (embora seja um pouco longo), acredito que ficará mais claro qual era a minha intenção.
Eu penso que linguagens são como uma espécie de carro. Cada carro tem vários pontos fortes e fracos, custa um valor diferente para comprar e, embora pareçam cumprir o mesmo papel, acredito que se parecem nesse aspecto de perseguirem valores diferentes. Claro, também acho natural ter um carinho e amor especiais por um determinado carro. Eu também amo o meu carro e confio na fabricante dele.
Mesmo assim, eu também tenho pontos de insatisfação e reclamações em relação ao meu carro, e avaliadores que fazem reviews periódicos de modelos de carros sempre compartilham suas análises comparando-os com modelos concorrentes em vários aspectos. Se alguém disser que o câmbio do meu carro não é muito bom ou que ele consome muito combustível, eu realmente não fico feliz em ouvir isso, mas, ainda assim, tento separar o motorista de seu carro. Além disso, procuro conhecer melhor o carro que dirijo, tanto em seus pontos fortes quanto fracos. Talvez eu venha a dirigir outro carro no futuro, mas a experiência de direção que tenho agora ainda será útil nessa hora.
Na versão resumida eu não consegui mencionar muito isso, mas, no texto principal do blog, concluí dizendo que, apesar dos pontos frustrantes do Go, ele ainda tem mais vantagens, então pretendo continuar usando (= dirigindo). Como cada linguagem busca valores e vantagens diferentes, eu costumo tentar usar o máximo possível de linguagens variadas (= veículos). Esse também é o motivo de eu querer deixar de lado um runtime JS que eu já usava bem para migrar justamente para a linguagem Go.
Achei que tinha escrito o texto com bastante cuidado, do meu jeito, para evitar ao máximo discussões desnecessárias entre linguagens, mas, ainda assim, se houver Gophers que tenham se sentido incomodados ao ler este texto, espero mais uma vez que possam relevar isso. E, para encerrar este comentário, deixo claro que sou um programador romântico que ama até a linguagem PHP, tão criticada por tanta gente!
No texto original, o autor apresenta sua própria análise sobre as partes lentas e, ainda assim, explica por que continuaria usando Go; por isso, não entendo muito bem por que você interpretou este texto como um juízo de valor.
Embora seja TMI, a biblioteca std do Go vem perdendo desempenho com o passar do tempo. O principal motivo é o trade-off com as inúmeras vulnerabilidades de segurança reportadas, à medida que vários recursos são adicionados para cumprir os padrões RFC.
Recentemente, com a necessidade de passar pela certificação FIPS, a expectativa é que a perda de desempenho provavelmente aumente um pouco mais.
Eliminar todo esse contexto e simplesmente escrever que o desempenho é ruim em um cenário específico e extremamente simples me parece suficiente para levar muita gente a uma interpretação equivocada ;_;
Estou esperando a versão 1.0 do tsboard hehe
Agradeço por esperar! Vou seguir trabalhando com alegria hehe
Como o JS usa JIT, acho que não há muito motivo para ele ser lento.
Exceto por multithreading, estabilidade etc..
Algo que eu também descobri(?) de novo com este benchmark, e acho que dá até para afirmar isso com certa segurança, é que o nível de estabilidade também não apresenta grandes problemas. É verdade que multithreading definitivamente exige orquestração (não sei se é assim que se escreve), então acaba sendo um pouco incômodo.
O site não está funcionando; sou só eu?
Olá! Obrigado por avisar nos comentários, haha. Ainda não consegui migrar o site para uma hospedagem, então às vezes há problemas de acesso! Vou tentar resolver isso o mais rápido possível. (Por enquanto, um mini PC aqui em casa está trabalhando pesado 😂)
Ah, agora está funcionando. Vou ler direitinho!
Mudei o site de um mini PC no quarto para um servidor virtual do tamanho de um cômodo...! Hoje, inesperadamente, muita gente apareceu e acabou tendo que ir embora sem conseguir acessar, mas agora informo que não haverá mais problemas!
Fico curioso para ver se o resultado seria diferente ao testar com o driver
github.com/jackc/pgx/v5e PostgreSQL.Também fiquei curioso se esse resultado é algo limitado ao mysql ou se se aplica a todos os cenários que usam banco de dados. Acho que em algum momento outras pessoas vão compartilhar os resultados também haha