Executando verificação de segurança...
27
matheusand
1 min de leitura ·

Você não precisa de uma linguagem de programação mais rápida...

Quando programadores debatem sobre problemas de latência em sistemas legados, não é raro ver alguém sugerir que o problema é a linguagem de programação utilizada.

"Python é lento demais! Deveria ter usado Rust."

Acontece que eu NUNCA me deparei com um cenário em que o verdadeiro gargalo é a linguagem.

Você não precisa de uma linguagem de programação mais rápida se:

  • as querys estão feitas do modo errado
  • o código não diferencia o que deve ser síncrono e assíncrono
  • a aplicação não tem cache (quando aplicável)
  • a aplicação consome memória como se não houvesse amanhã

Se o time não se preocupa com qualidade de software, a linguagem não vai fazer milagre.

Bons programadores são capazes de refatorar.

O meu ponto aqui é que frequentemente o diagnóstico do problema é feito da maneira errada. É muito confortável olhar um sistema ruim e dizer que o problema é a linguagem. Você terceiriza a culpa para os desenvolvedores da linguagem/framework e ainda ganha argumento para reescrever tudo na sua linguagem favorita.

Carregando publicação patrocinada...
5
vitorramalho

Em mundo em que todo dia surge um framework novo, poucos se importam em compreender como as coisas são construídas. Valorizem o conhecimento de base e o resto virá por consequência. Abaixo as APIs com queries N+1.

3
depaula

O padrão N+1 é o que mais pega dev junior. Ele implementa, passa nos testes unitarios, passa no teste de integração ai um tempo depois o sistema recebe carga e descobre a bomba.

Off by one é que mais pega dev pleno. Ele testa quase tudo, só esquece de testar aquela feature (com skin de bug) de exceção que acontece em ano bissexto, em dia de lua cheia.

CQRS é que geralmente mais pega os senior. Ja vi muito senior chorando com deadlock que na epoca só outro dev e Jesus entendiam. Depois que o outro dev vazou só Jesus.

2
1
2
uriel

O pessoal infelizmente esquece que um dia foram iniciantes que não sabiam das coisas!

E soltam jargões tecnicos pra todo lodo lado sem pensar naqueles que são iniciantes!

Buscar o google pode chegar na resposta errada.

Se a pessoa sabe o que é, sabe onde esta resposta correta. Não dói os dedos postar o link para ajudar as pessoas!

Abraços

1
MullerHub

Obrigado mestre, é bem isso mesmo, vi as citações acima e fui pesquisar, mas as materias e docs que encontrei não eram 100% iguais aos links que você enviou acima.
Como iniciante autodidata (sem faculdade ou professor indicando o que estudar) tudo é mais dificil, comecei a estudar js (no inicio era só html, css, sistemas e versionamento de codigo) esses ultimos 6 meses foi com typescript, nodejs com muitos frameworks, react e next e começou a pesar bastante, peguei livros pra ler mas mesmo assim sem um professor é bem tenso
Sobre algoritmos estava estudando esse livro: Algoritmos - Teoria e Prática é bom, mas gigante, to no começo ainda

mas mesmo assim, só livros sem um tutor continua sendo tenso a fixação das boas praticas e o que é correto ou não...

1
1
1
uriel

Recomendação simples!
Quando falarem de algum coisa. Coloquem o link para o assunto.
Wikpédia o outro site explicando!

Aqui temos iniciantes e gente que é antes do iniciante!

O que é o problema das queries N+1?

Como você conhece o problema, conhece a resposta correta.
Pode linkar o texto com a resposta certa.

Você pode falar para pesquisarem! Mas e se chegarem nas respostas incorretas?
Melhor já ajudar no começo!

Abraços

1
marcdantas

Problemas de velocidade são MUITO comuns em contextos diferentes, concordo com seu ponto. Os problemas (na maioria das vezes) estão localizados sobre a codebase em si. Ou seja, na qualidade do código.

Mas acho que não se deve descartar a possibilidade de mudança de linguagem. Eu já desenvolvi vários projetos em Python e Ruby que tinham problemas graves de velocidade (antes de dizer algo, eu chequei o código e estava tudo conforme o normal e o mais rápido possível).

Essa discussão é infinita. Porém podemos concordar que, na maioria das vezes, o problema está no piloto, e não no carro

3
cauachagas

Sua fala faz sentido para um mundo Web, onde o objetivo é criar e consumir serviços.

Eu era pesquisador na de Petróleo, mais especificamente, Sísmica. Então o objetivo era processar volumes gigantescos de dados. Então o "Acontece que eu NUNCA me deparei com um cenário em que o verdadeiro gargalo é a linguagem", nesse meu caso, já me deparei. E digo "Python é lento demais! Deveria ter usado Fortran." (é o que pessoa mais usa nessa área).

Seismic Animation

Mas o Python mesmo tem várias soluções pra deixá-lo rápido (a maioria é feito em C/C++). Mas o cara tem que saber fuçar. Se se só pegar direto em Python puro, irá sofrer rsrs.

1
matheusand
Autor
Autor

Para projetos novos, o debate sobre qual linguagem utilizar é muito importante.
Não adianta querer usar python para criar um aplicativo mobile, ou querer usar Javascript para criar um modelo de ML...

O meu ponto aqui é que frequentemente o diagnóstico do problema é feito da maneira errada. É muito confortável olhar um sistema ruim e dizer que o problema é a linguagem. Você terceiriza a culpa para os desenvolvedores da linguagem/framework e ainda ganha argumento para reescrever tudo na sua linguagem favorita, quando a solução mais viável para o negócio seria a refatoração.

2
cauachagas

Ah, sim. Agora ficou claro.

Realmente é isso. O gargalo está na forma em que foi escrito.

Tanto é que tem projetos grandes que são feitos em monolíticos como Github (Rails), YouTube (Django) e stackoverflow (acho que é Rails), que são linguagens "lentas" mais aguenta mais porrada que muito projeto feito em Go ou Rust. Não adianta. Código é ruim é código ruim, não importa a linguagem escrita.

3
letsaguiar

Aqui vai uma opinião um pouco impopular: esse é um problema do mercado de tecnologia no Brasil.

As empresas não estão realmente preocupadas se você entende sobre eficiência de código. Fazem processos seletivos que verificam apenas sua capacidade de escrever instruções sequenciais e performance só vira uma prioridade quando os custos de manter um produto ineficiente no ar ficam altos demais.

Já fiz vários processos seletivos na vida e posso contar nos dedos quantos deles exigiam que eu soubesse sobre complexidade, algorítmos, estruturas de dados, etc.

A soluçao para códigos ineficientes quase sempre é escalonar as máquinas e isso tem dois custos: o financeiro (gastar mais com serviços cloud) e o tech (seguir operando e construindo novas soluções em cima de um código legado que vai dar problema no futuro).

Os profissionais são, em geral, moldados pelas demanadas do mercado. Passar a demandar seriamente conhecimentos sobre complexidade de tempo e espaço (como já acontece em outros mercados pelo mundo) parece ser o primeiro passo para construir um ecossistema de tecnologia mais consciente no Brasil.

1
uriel

Aqui vai uma opinião um pouco impopular: esse é um problema do mercado de tecnologia no Brasil.

Onde mais leio sobre primero fazer e depois pensar em perfornance é fora do Brasil.

Pq uma coisa é certa, não adianta pensar em microotimização se o produto não vende.
Você vai gastar tempo dinheiro e não vai ter retorno.

Como nos textos que li - fora do BR - é melhor fazer, vender e depois pegar onde tem gargalos e otimizar - até pq otimizar tudo de primeira vai fazer o código não ser lindo e simples rsrsrs

Sempre quando um programador tenta adivinhar o futuro ele erra!

2
2
tieris

Além disso, é importante saber as peculariedades de cada linguagem, de forma que você consiga desenvolver um código da forma mais eficiente possível, e também, simplificar o código, mantendo sua complexidade baixa.

Por exemplo, em java, as strings são "imutáveis", então toda vez que você vai contatenar uma string com outra, o java pega o valor das duas strings na memória, cria uma nova string com a concatenação das duas originais em um novo espaço de memória e "apaga" as originais. Se você precisa concatenar muitas coisas, isso ficaria extremamente lento, sendo mais eficiente você criar um StringBuilder, adicionar todas strings à ele, e depois converter isso para String...

1
1
andrepiske

Concordo: você precisa de uma linguagem de programação mais rápida!

oops, deixa eu explicar! Você pode fazer em C ou Rust e, na hora de rodar seu código, ele vai voar! Porém vc vai levar muito mais tempo pra programar qualquer coisa nessa linguagem e esse é o pulo do gato:

Vc não precisa de uma linguagem que rode mais rápido, mas precisa de uma linguagem que seja rápido de vc programar as coisas.

Eu iniciei na programação com C e C++ e queria otimizar tudo, deixar pra rodar o mais rápido. Mas conseguia fazer pouca coisa. Depois que descobri Python e, posteriormente Ruby, vi que realmente são meio lerdas pra rodar algumas coisas, porém a minha PRODUTIVIDADE aumentou drasticamente.

No mundo web, não faz muita diferença pro usuário uma página que leve 1ms pra carregar e uma que leve 100ms (note: 100x mais rápida). Porém faz muita diferença, pra uma empresa, que a produtividade seja 100x (e até muito menos que isso) melhor por se usar uma linguagem mais produtiva.

Além disso, como vc disse: o gargalo quase nunca é a linguagem, mas sim a qualidade do código, o acesso banco de dados, uso de caching etc

1
tarcisiodelmondes

Se uma página carrega-se 100x mais rápida eu ficaria feliz da vida, talvez não faça diferença pro usuário que tenha uma internet boa, mas para quem não tem esse luxo(Eu não tenho), a pagina estar mais otimizada possível faz total diferença no meu caso.

O problema não é sempre a linguagem, mas tem casos específicos, tem computadores mais limitados, então linguagens como C e Rust são essenciais, Não é atoa que tem empresa que usa C# para cria aplicações web, mais claro que isso é a exceção, a padaria do senho Chico não precisa disso. Então sempre é uma balança, temos o Node que é até rápido mais gasta muita memória ram de acordo com a quantidade de usuários vai aumentando, temos o Rust que gasta bem menos ram é mais rápido e mais seguro, só que é mais complicado e mais complexo de se dar manutenção. Mais casos são casos então, sim, você precisa dos dois, uma linguagem mais rápida e uma produtividade melhor também.

1
1
brunofreire

E os microsserviços?

Vale ressaltar que depende muito do que você de fato busca realizar. Cada linguagem de programação tem seu objetivo, por exemplo, existem cenários específicos, por exemplo iterações de grande quantidade de items, onde o prórpio PHP irá ser muito mais veloz que o NodeJS. Tudo depende do que você quer.

Outra coisa é a arquitetura e boas práticas. Uma arquitetura assíncrona é a chave da velocidade nas tecnologias Web. O uso correto da linguagem também te dá muito mais potência. Se você fizer uma tarefa de repetição árdua, como um loop enorme, concatenando em cada iteração usando ${} será mais lento que com "" + "". Pequenos detalhes assim, em execuções curtas, não alteram em nada, mas es tarefas de alta repetição, fazem uma diferença enorme.

As microtimizações somente servem para tarefas repetitivas. No final, tudo depende do que seu código faz. Existem tarefas, como produção de raltório, que não dá para otimizar as querys pois você precisa de todas as linhas e dados de uma tabela para poder fazer um cálculo matemático.

E é nessa ideia que também surgiram os microsserviços: fazer tarefas específicas em ambientes especificos, com desenvolcedores específicos para conseguir a melhor velocidade de produção de código, performance e manutenção.

1
matheusand
Autor
Autor

O meu ponto aqui é que frequentemente o diagnóstico do problema é feito da maneira errada. É muito confortável olhar um sistema ruim e dizer que o problema é a linguagem. Você terceiriza a culpa para os desenvolvedores da linguagem/framework e ainda ganha argumento para reescrever tudo na sua linguagem favorita.

1
brunofreire

Sim eu entendo plenamente, principalmente programadores Júnior ou até mesmo Pleno. Como de fato não conhecem como as linguagens de programação funcionam a fundo (vivem aprendendo somente Frameworks), podem ter essa impressão de que: o problema do código deles estar lento, é a linguagem.

Mas nunca esquecer que a ordem de importância na optimização de código deve ser mais ou menos assim:

  1. Identificar parte do código que está lenta
  2. Refatorar código
    2.1 Checar boas práticas
    2.2 Buscar outras maneiras de fazer a mesma tarefa baseando-se em
    2.2.1 Algorítimos especializados (não reinventar a roda)
    2.2.2 Mineirar soluções parecidas no Stackoverflow ou até mesmo no ChatGPT3
    2.2.3 Buscar em código aberto de outros projetos, soluções similares
  3. Buscar bibliotecas que tenham o mesmo fim
  4. Se já usa uma biblioteca e está lento ou continua lento
    4.1 Buscar outras bibliotecas que tenham menor footprint
    4.2 Criar sua própria biblioteca de maneira Open-Source, se caso não houver nenhuma outra alternativa na comunidade
    4.3 Ou até mesmo não usar bibliotecas. Ás vezes, nossa primeira escolha é não reinventar a roda, mas existem situações onde que, para extrair a maior performance possível, você deve "enxugar" os "middlewares e pesos desnecessários" das bibliotecas disponíveis, para chegar a melhor performance.
  5. Trocar arquitetura
    Grande parte dos problemas se resolvem com a arquitetura adequada para aquela função de código.
  6. Microsserviços pagos
    Alternativas em outros serividores tipo API HTTP
  7. Criar seu próprio microsserviço em um ambiente especializado com menor footprint
  8. Trocar de linguagem de programação
  9. Usar linguagens de mais baixo nivel, como C e C++
  10. Criar sua própria linguagem de programação
  11. Escrever em Assembly
  12. Desistir do projeto kkkk

Brincadeiras à parte nos últimos tópicos, a questão é que a maioria dos problemas se resolvem até no passo 5!

1
uriel

Ou faz como o facebook.
Eles tem números tão grandes, tão grandes que eu mesmo não imagino tudo rsrsr

Eles tinham PHP. Eles não mudaram do PHP pra C por exemplo.
Eles mudaram o compilador

Primeiro com o HPHPc - já descontinuado
E usam o HipHop Virtual Machine hoje!

Claro que eles tem microserviços em diversas linguagens, sabemos disso pq eles mesmos disponibilizam em código aberto N ferramentas em n linguagens.

Mas saber que eles resolveram mexer na forma como o PHP interpreta e compila foi muito interessante - eles podem dinheiro não falta ali! Nós meros mortais em empresas de sowtare não complexo não temos esse privilégio!

Abraços

1
0