Porque GO é 3 vezes MAIS LENTO que RUST? E python 150x mais lento que C?

[@ethi8128]

tua didática é fenomenal. ultimamente tá difícil eu ficar focado em um vídeo de 10min sem perceber kkkk mas acabei vendo teu vídeo completo sem pular nada e sem nem perceber o tempo passar kkkk

[@gabrielkemmer]

Isso é verdade vi o vídeo todo e nem me liguei que passaram 10 minutos

[@faustoyuuki6826]

eu n fazia ideia q o video teve 10min, mas msm assim eu tive q colocar a velocidade em 1.3x pq c n eu n consigo ficar focado. Tenho q parar de ver tiktok e ler mais livros para ter o foco de volta

[@ethi8128]

@faustoyuuki6826 larguei do tiktok por isso. tava acabando com o meu foco. impaciência tava explodindo em mim.

[@custodiogomesbarcellos4972]

É claro que algumas linguagens, como você colocou, serão por definição mais rápidas que outras, mas acho que seu vídeo desmascara um pouco esses benchmarks. Todos comparam por loops e isso pode não refletir a capacidade dela na prática. E você MUITO BEM demonstrou que uma boa linguagem precisa de um bom programador que entenda e saiba suas limitações. Não existe um grupo, ou email do Google de desenvolvedores do Go que você possa fazer essa demonstração ou upload do video? Manda pro Rob Pike. Achei bastante pertinente principalmente pra eles. Ótimos vídeos os seus, por favor continue.

[@filipedias6707]

Dado o pragmatismo dos core developers do Go, justificar uma otimização apenas referenciando um benchmark de linguagens com um fibonacci ou um for loop, talvez não seja motivo que levem em consideração. Além disso o Go surgiu justamente porquê os sistemas da Google, feitos em C++ demoravam bastante pra compilar. Essa otimização teria impacto justamente no tempo de compilação de Go, que hoje é um absurdo de rápido

[@tiagobecker8617]

Parabéns, conhecimento tacito, fluido e sem enrolação. Muito bom!

[@luisfernandomoraes9778]

Mostra como tu aplicou o profiling pra descobrir a otimização mano! Show de bola o conteudo, parabéns!

[@avilyre]

Pedro brabo demais! Virei fã so com esse vídeo

[@phifnmg]

Cada conteúdo que o Pedrão posta e fantástico !

[@filipedias6707]

Nossa, tu matou uma dúvida que tava a muito tempo na minha cabeça. Esse vídeo tá bom demais 🤌

[@douglas5009]

3:54 tentei reproduzir o benchmark do código Go, com e sem a modificação que mostrou no vídeo, porém não chegou nem perto do 614.9ms. O que consegui foi: antes: 2.329 s depois: 2.105 s Usando a versão go1.23.4 linux/amd64.

[@NetinhoTeixeira]

Acho que a máquina utilizada também influencia.

[@manoelnt0]

​@@NetinhoTeixeira sem dúvidas influencia! Com certeza!

[@_samuelcamilo]

Parabéns mano, que conteúdo topppp!

[@renanlido_dev]

Pow, total, super concordo com a tua visão sobre linguagens. Muita gente trata como se fosse time de futebol. Tenho visto até a mesma tendência quando se trata de política. Ninguém quer olhar o quadro geral e olha só dentro da própria bolha, um saco.... Eu evito até entrar nesses debates pq não levam a nenhum lugar... Enfim, muito bom te ver lançando outro vídeo, amo a sua didática!!!

[@SrAzion]

Muito bom. Ficou boa explicação 5:56 todo mundo esquece do AsM

[@HugoNathanBR]

Conteúdo excelente!!!

[@phenpessoa]

Obrigado!

[@thejman4466]

Fala, Pedro. Você já fez um vídeo sobre profilling em aplicações Go? Seria bacana esse conteúdo vindo com sua didática.

[@victoraraujo1255]

Obrigado Pedro, agora não vou conseguir dormir até saber o porque que uma divisão é tão custosa a nível de assembly... Brincadeiras a parte, mais um ótimo vídeo como sempre

[@vinimooraess]

Acho que seria pelo mesmo motivo que pra gente é mais fácil multiplicar algo por 3 do que dividir por 3: Pra multiplicar vc só precisar somar x + x + x. Ja pra dividir é um processo mais iterativo, tem que multiplicar o 3 pelo maior numero divisivel por x, anotar qual numero foi, pegar o restante, colocar um 0 do lado, e repetir o processo n vezes até chegar na precisão desejada ou no resultado.

[@Lohan_Guedes]

VIDEO NOVO!!!! simbora!!!

[@emanoelinfinity]

Esse vídeo é excelente para os iniciantes emocionados. Claro que esses comparadores não servem pra nada*, e o mais importante é saber porque.

[@eduardopereira2431]

Cara um detalhe interessante do Println (não sei a fundo) deve ter algo relacionado com buffers que deixa lendo milhões de prints no stdout, certa vez eu fiz um teste e diminui drasticamente (mas muito mesmo) substitui por um strings.Builder que só printava o resultado fora do loop.

[@isaccabral1291]

Parabéns pelo vídeo. Muito bom, difícil um vídeo me prender assim até o final. Qual programa de Benchmark você usou?

[@phenpessoa]

Foi o hyperfine

[@adiliophi]

Otimo conteudo!

[@phenpessoa]

Obrigado!

[@shark3ds498]

Demais esse video!

[@TheRobsantos777]

Eu nem acredito mais nesses benchmarks, se fazer loops em C usando a biblioteca stdio.h ela vai ficar mais lenta, e sabemos que uma aplicação complexa em C++ com um bom time de programadores vai ser mais performática que zig por diversos fatores, BENCHMARKS só são numeros.

[@gabrielmartins7642]

O dart que me surpreendeu

[@henriquedeandrade717]

Eu legal que só trocar CPython pelo PyPy fez o python rodar muito mais rapido. O que eu JIT não faz não é mesmo kkkk. Da para ver o mesmo comportamento em outras. Com JIT e sem JIT.

[@keuwey]

Inclusive o cpython agora recebeu um novo jit experimental na versão 3.13. E antes disso já tinha o interpretador adaptativo, que deixa o código um pouco mais rápido. Além disso, já existia o numba, que é um jit compiler pra python que usa o LLVM que ele mencionou no vídeo. O python está ficando cada vez mais performático.

[@natanael4441]

O Benchmark de Lua tá tecnicamente errado também mas é legal ver a posição sem otimização

[@emeci430]

show de bola!

[@phenpessoa]

Valeu!

[@vitorbrussolo9651]

muito bom conteudo

[@feliperesende4505]

O que muita gente não entende é que algumas linguagens PRECISAM ser mais lentas para conseguir oferecer certas features, favorecer certos designs ou conseguir rodar em ecossistemas muito específicos. Você troca performance por praticidade.

[@MarceloSantosSCS]

Parabéns pela didática, o vídeo inteiro é show de bola. Apenas uma curiosidade: Que editor de código tu usa? Me parece VSCode. Achei maneiro a forma como ele destaca as nuances das linguagens.

[@paulobitfranca]

O motivo de Rust ser mais rápido do que Golang não é apenas pelo fato de RUST não ter GC. A prioridade de Golang é ter uma compilação rápida. Já Rust abre mão da velocidade de compilação em favor de executar uma otimização brutal no código ao compilar, convertendo abstrações mais complexas do código em instruções de baixo nível mais simples, entre muitas outras coisas. Tudo isso com o objetivo de entregar um binário final o mais enxuto e eficiente possível. É por isso que Golang compila anos-luz mais rápido do que Rust, já que, como já dito, a prioridade de Go é uma build rápida, sem se preocupar muito com otimizações.

[@joaoantoniocabral]

Uma vez teve um evento com um desafio de criar uma API onde seria executado um teste de stress e comparado as performances. O pessoal conseguiu boas performances com algumas linguagens não tão famosas por performance. Não lembro o nome do evento (tentei pesquisar rápido aqui), mas eram testes reais como consulta em uma API que buscava no banco de dados, salvava dados e etc.

[@Mth-Ryan]

Muitas linguagem que são consideradas lentas se dão bem nesse tipo de teste por um motivo muito simples: as bibliotecas que utilizam para comunicação http são escritas em c ou outra línguagem de sistemas. Na verdade esse é o caso ideal para linguagens de script como python ou ruby. Criar bibliotecas performática em c como o web server pulma e montar sua aplicação em torno delas. Infelizmente com a hiper especialização dos programadores isso se perdeu um pouco. Hoje vemos aberrações como o compilador de typescript sendo escrito nele mesmo. Vai entender.

[@brunof2p]

Tem a rinha do backend que o akita fez uns 3 vídeos sobre, no final ele conseguiu obter pontuação máxima em todas as linguagens da rinha

[@joaoantoniocabral]

@@brunof2p exato, era esse que queria lembrar mas não lembrava o nome!

[@richardelesbao]

Mas naquele desafio não era muito com a linguagem em si, e sim saber usar atomicidade do banco de dados

[@TheMathues123]

python 150x mais lento que C. Você programando em C: 150000x mais lento. Eaí, qual tu escolhe ?

[@vitorcorrea6375]

Depende onde será usada. Por exemplo, sistemas embarcados. Imagine programar o sistema de um avião em Python, sendo que a resposta tem que ser de forma instantânea.

[@Toda_Ciencia]

nunca que em C é 150000x mais lento, kkkkkkkkk! mas aí está a resposta: depende em sistemas onde performance é essencial, como kernels de sistemas operacionais, jogos, banco de dados, navegadores, etc. C é a escolha em sistemas onde performance não é tão essencial, como web apps, scripts, etc. Python é uma escolha

[@TheMathues123]

​@@Toda_CienciaEu não disse a linguagem, eu disse "você" usando a linguagem. Quanto tempo leva pra tu entregar features em C ? sacou.

[@ViniciusCosta-bi9bq]

​@@vitorcorrea6375 95% das pessoas trabalham em front, back, mobile ou data science

​@@TheMathues123depende do nível de conhecimento sobre a linguagem..

[@segredosdefamilia9685]

Se fizer isso com apenas 1000 iteracoes no loop, melhor com ou sem a otimização?

[@TheGabrielMoon]

Tem outro detalhe sobre esse bench: o teste em si não está testando o loop, mas sim divisões.

[@ruanpetterson2072]

Uma correção: Rust tem bastante potencial em ser mais performático sim em relação a C. Isso acontece muitas vezes por causa das otimizações do LLVM com pointer aliasing. Enquanto em Rust essa marcação é feita automaticamente com ajuda do borrowck, em C isso é manual e muitas vezes negligenciada.

[@Ellipsis_]

o q aprendemos aqui é q as linguagens sao apenas abstrações de assembly, e principalmente entre as compiladas a diferença vai estar na otimização de um compilador pra outra, pq vc não esta impedido de fazer uma otimização de compilador. e lembremos q a dor dos desenvolvedores de go, foi o tempo de compilação de c++, então ta ai o motivo da decisão de tornar o compilador mais rapido em detrimento das otimizações de compilador

[@thiagoportellaferreira1506]

que legal. Foi proposital então. Eles deixaram para fazer as otimizações no código mesmo.

[@Full-Stack-Go-JavaScript]

Pode tirar minha dúvida de uma vez por todas: usar Go para o backend de um e-commerce, com análise de vendas, cálculo de custos e processamento normal de grandes volumes de dados, compensa?

[@henriquedeandrade717]

Depende

[@ojuliomiguel]

Vou te dar a resposta: tanto faz, mano! Tu pode até fazer em delphi. O que vai ser relevante é o quanto você domina e quem vai manter esse seu backend. Qualquer lang vai dar bom - qualquer uma!

[@elloxin]

Amigo, vai depender mais da arquitetura do seu projeto do que da linguagem. Recomendo tentar utilizar o máximo de caching possível, isso que vai dar velocidade no seu sistema.

[@rianbreno134]

Uma dúvida, o que você considera "grandes volumes de dados"?

[@Full-Stack-Go-JavaScript]

"@rianbreno134, usei a IA de voz e ela explicou errado. Estou me referindo a um CRUD padrão mesmo, um e-commerce normal e ir escalando com o tempo. Atualmente uso WordPress, porém trabalhei bastante tempo com front-end e sei montar um com back-end do Medusa.js.Porém, quero algo sólido. Desisti do JS porque surgem muitas atualizações e ainda tem o C++ por trás. o Go é feito só em Go."

[@hououink]

"O compilador de Go é escrito em Go"... eu não sei se eu fico feliz ou fico com medo

[@leandrocavalcante769]

massa!

[@homerobaroni1655]

Luajit é brabo, já superou C em alguns casos

[@MayconRodrigues1]

Eu já estava desconfiando. Meu código em Go é sempre mais rápido do que outros códigos que fazem a mesma coisa. É tudo questão de saber otimizar o código e não esperar pelo compilador. Neste caso Java seria mais rápido porque a JVM otimiza o código.

[@casadogaspar]

Se algu\em tiver paciencia de testar printando de formas diferentes provavelmente vai conseguir tempos diferentes e ate melhores. PS (nao sei onde esse teclado tem os acentos haha)

[@CapiEtheriel]

to chocado que `tmp = a[i]; tmp = 0` altera o valor de `a[i]`. eu esperava que alterasse o valor de `tmp`, mas não de `a[i]`.

[@phenpessoa]

tmp = 0 não altera o valor de a[i] não.

[@smanzoli]

Python se compilado (e é muito fácil JIT no Python), ele fica muito rápida, cerca de apenas 4x mais lento que C... ou igual C não otimizado. As pessoas esquecem que um código Python do mundo real está na verdade rodando C a imensa parte do tempo.

[@WendelBrito-s8s]

Sobre o comentario final, Zig, Rust e C estão praticamente empatados po, ou 0,518 é muita diferença para 0,515 ou 0,510 ? rsrs

[@erosserver8142]

Acho que você deveria fazer a mesma mudança no Rust e veja a diferença.

[@phenpessoa]

Não tem diferença. O código de máquina (assembly) é o mesmo. O compilador de rust faz a otimização automaticamente.

[@luxaas9978]

mas pq java que é uma linguagem hibrida ficou na frente de go que é uma linguagem compilada?

[@TheGabrielMoon]

jvm

[@leonardo.fernandes]

Porque a JVM faz muitas otimizações

[@phenpessoa]

Exatamente isso que o pessoal respondeu: otimizações. Mas, depois da alteração no código Go, ela volta a ficar na frente.

[@RicardoSilvaTripcall]

@@leonardo.fernandes Mas o JIT da JVM só faz otimizações depois de algumas milhares de execuções, sem contar que analisar o código em tempo de execução pra ver se ele pode ser otimizado ou não, também pode atrapalhar na execução do código principal ... resumindo, aguardaram a JVM "aquecer", para começar a medição, no mais, é apenas a execução de um loop, o JIT da JVM não faz milagres, principalmente do jeito que o pessoal programa java hoje, cheio de abstrações, patterns etc ... em um cenário normal, os especialistas nem consideram o JIT, pois existem zilhões de regras que podem impactar ou não a otimização do código.

[@paulobitfranca]

@@RicardoSilvaTripcall Mas será mesmo que Java já não otimiza na compilação? Confesso que fiquei curioso. Vou depois colocar uma JVM zerada aqui, só pra poder executar esse teste.

[@carlos-rian]

Perde um pouco de tempo em compilação não. Perde tempo pra caramba, rust é muito bom e tudo mais, eu amo. Mas é uma merda para compilar, demora demais, se vc add um monte de dependências então, pode acreditar que vai algum tempo. Go é quase uma linguagem dinâmica no desenvolvimento de tão rápida que são as checagem. E claro, é aquilo, tudo tem um overhead ou uma troca, não dar para ter tudo.

[@henriquedeandrade717]

Quem nunca ficou 3 horas compilando uma lib C/C++ né kkkkk

[@carlos-rian]

@ exatamente, pode até ser rápido depois de compilado. Mas gasta o dobro para desenvolver. Mas é a vida haha.

[@henriquedeandrade717]

@@carlos-rian Sim. Eu trabalho com python. É em python é facil usar codigo C, C++ e Rust compilado juntos com o python. Python é otimo como linguagem cola

[@carlos-rian]

@ eu também, atualmente quando quero fazer algo mais performático, eu uso a bridge PyO3 do Rust para Python, funciona muito bem. Mas é como vc falou, tem que esperar um tempo para compilar. Mas Python é vida.

[@paulobitfranca]

Uso Rust desde 2023, e acho um primor de linguagem. Rust demora mais pra compilar pois faz uma otimização brutal no código, com o objetivo de entregar um binário final mais rápido. Já Golang opta pela velocidade de compilação, sem se preocupar muito com otimizações. O que é melhor? Build rápida ou binário final mais rápido? Infelizmente, tudo tem vantagens e desvantagens...

[@DataAnalyst1973]

Portas de 2025 e as pessoas perdendo tempo com isso...

[@mariaeduardasantanadolce352]

E você aqui também...

[@paulobitfranca]

De forma alguma esses testes são perda de tempo, quando feitos com seriedade. Sempre se aprende algo novo, como por exemplo o autor do vídeo citou ter entendido, através desse teste, a questão da otimização que Rust faz e Golang não.

[@irineu6169]

wow

[@cferrado]

comparação complexa, luajit mesmo pode ser mais rápido que quase qualquer linguagem não compilada... até cair num NYI, alocar num loop, ou precisar de threads

[@fudencio]

caras e bocas nessa thumbnail e conteudo meio DÉVI EXCUTA SÓ

[@kommanderkeen]

Video fantástico! Por que Zig não tem tido a mesma atenção que Rust se parece ser mais rápido e mais parecido com C?

[@ViniciusSoaresBatista]

Zig eh mais nova, comunidade menor, e só ganhou notoriedade recentemente. Rust é o oposto

[@ViniciusCosta-bi9bq]

Porque gostam de zoar python de graça?

[@jcbritobr]

Rust faz muitas otimizações. Muitas mesmo. Eu não vejo esses bench porque é tudo meio inútil. No final, o que conta mesmo é a capacidade do compilador gerar assembly.