Sem duvida você ja ouviu que existem linguagens rapidas e lentas... e se eu te falasse que isso NÃO E VERDADE...
Esse video do Augusto Galego e sem duvida um dos mais lucidos da atualidade -> Video Explicando
Esqueça essa Tabela
Tem alguns pontos no vídeo que gostaria de fazer alguns adendos. Primeiro: ele comentou que não existe alguma característica específica da linguagem que determine se ela é mais rápida ou lenta e tudo depende do runtime. Bom, isso não é necessariamente verdade. A maioria da linguagens tem gerenciamento automático de memória, e por mais que você troque o runtime você jamais pode tirar dela este conceito sem modificar como elas funcionam a nível de semântica. Outra coisa: tipagem. Tipagem influência na performance? Sim. Pois é pela tipagem que otimizações podem ser realizadas durante o runtime como por exemplo compilação just in time. O JIT de linguagens não ripadas em geral tenta adivinhar qual tipo a função recebe e retorna.
Então sim. Características da linguagem podem afetar a performance. E a tabela que está no post pode variar as linguagens de posição dentro do seu próprio bloco mas em geral representa a performance que observamos no dia a dia. Pois se aplicarmos a todas as linguagens as mesmas otimizações a medida do possível: Python, Ruby e PHP continuariam sendo mais lentas do que Java, que por sua vez continuaria sendo mais lenta que C. Isso no geral, talvez em pontos específicos não seja verdade. Para referência, a linguagem dinâmica mais rápida é provavelmente common lisp com o sbcl.
Contudo. Eu tenho que dizer que a preocupação em performance é muito superestimada. Para a maioria dos problemas que resolvermos no mercado a performance da linguagem é irrelevante, e a menos que você esteja processando um número absurdo de dados, ou realmente monstruoso de requisições. Eu não vejo por que você estaria se preocupando com isso (ps: esse comentário é pra qualquer um que leia, o "vc" não é específico para o autor).
Contudo é um vídeo muito interessante e eu concordo com boa parte dele. Ele traz muitas informações interessantes para mostrar que nem tudo é tão simples. Muito bom.
caraca... otima resposta sem duvida me surpreendeu, obrigado por compartilhar e sem duvida varias pessoas que estão iniciando vao pode achar meu TOPICO e ver sua resposta assim ajudando varias pessoas 🤝🤝🤝
Mas o buraco é um pouco mais embaixo. Enquanto quando as pessoas dizem que python é mais lento que C, querendo dizer de fato que CPython é mais lento que C, esses runtimes novos não são essa panaceia toda. Veja aqui nesse link que alguns construtos não estão implementados (ainda?), como:
async with, async for e async defclass (except for @jitclas)yield fromDá para fazer otimizações que, com certeza, são muito úteis, mas está longe de ser uma bala de prata no que diz respeito a desempenho em Python. Quem trabalha com computação científica em Python, se não puder delegar a computação pesada para uma lib em C/C++ (Stan, Pytorch, numpy), ou vai ter que implementar algo no braço, em C/C++/Rust, ou vai ter que combinar isso com essas otimizações.
E aí não dá para não falar do Julia, porque o Julia foi projetado do zero para operar com um REPL (aqui estou pensando em ciência de dados), para trabalhar de forma iterativa, mas também permite definir o tipo das variáveis, e não anotações de tipo, e realmente o Julia compila o código na primeira vez que você roda e daí para frente costuma ter um desempenho próximo ao C. Só que para fazer isso a linguagem foi projetada do zero para conseguir isso, com multiple dispatch dentre outras "mágicas". Creio eu que não seria tão fácil fazer isso com o Python e manter compatibilidade.
O Julia foi tão bem-sucedido nisso que as bibliotecas para computação pesada, como fazer MCMC, deep learning ou manipular data frames, é tudo feito em Julia puro. Claro, tem também uma série de otimizações que você tem que fazer para obter o melhor resultado possível, mas você está fazendo tudo em uma linguagem só.
No caso de Python o que poderia entregar isso é o Mojo, mas aí vamos ver...
Concordo com tudo que você escreveu, mas olhando pela otima do Mojo que eu testei e sem duvida e uma grande REVOLUÇÃO isso pode mudar porem so o tempo dira...
A explicação dele é boa porém não é totalmente precisa. Por mais que a ideia principal esteja totalmente correta, realmente a performance tem muito mais relação com o runtime, não está certo afirmar que a linguagem não influencia na performance. Então sim, existem linguagens que são mais performáticas do que outras.
É só estudar sobre implementação de compiladores para entender isso. Você verá que existem otimizações que são possíveis em algumas linguagens que não são possíveis em outras. Verá que linguagem X gera código menor do que linguagem Y. Verá que linguagem X precisa de um runtime muito menor e mais performático do que linguagem Y.
Isso tem a ver com a forma como a abstract machine da linguagem funciona. Se for muito distante de máquinas reais, mais código será gerado e um runtime maior é necessário para rodar o código escrito naquela linguagem.
É por esse motivo que existem as linguagens de programação que a gente chama de "linguagens de sistema" (como C, C++ e Rust mencionadas no vídeo). Essas linguagens são diferentes de linguagens como Python e JavaScript porque, justamente, foram projetadas para terem uma performance melhor.
Se não fizesse mesmo diferença na performance de uma linguagem para a outra, que argumento teríamos para não programar um sistema operacional em Python? Pense nas vantagens:
Pois é, então qual o motivo de não usarmos Python para programar um sistema operacional? Simples: performance.
Não importa o runtime usado, não importa quanto esforço seja empregado em um compilador de Python. A linguagem nunca vai alcançar a mesma performance de uma linguagem de sistema. Porque sua abstract machine é bem diferente de uma máquina real.
Sim, apenas dizer que uma linguagem é mais rápida que outra não quer dizer muita coisa. Vai depender da implementação do interpretador/compilador, do que a linguagem faz por baixo dos panos, etc.. Mas...
Apesar do teste ser antigo (2017), acho que ele está fazendo um pouco de salada. Para quem quiser ver realmente toda a história: Energy Efficiency
O vídeo está medindo consumo de energia com velocidade. O teste tem mais duas tabelas que são de tempo de execução (a que ele deveria estar apresentando para os testes dele) e memória. Considerando apenas o tempo de execução, C=1, temos que Chapel=2,14 (mais de duas vezes mais lento que C) e Pascal = 3,02 (três vezes mais lento que C). Mas, isoladamente, não significa muita coisa já que o consumo de energia do Pascal é menor que Chapel.
A comparação correta deveria incluir as três tabelas. Ou, se desejar apenas a velocidade mas colocando na mesma suíte de testes pois ele mesmo falou que aplicações diferentes podem gerar resultados diferente (motivo do teste ter 11 programas diferentes).