Eterna dúvida sobre linguagens para back-end

Uma coisa que eu sempre falo e não posso começar sem isto: pessoas aleatórias na internet não sabem todos os detalhes do seu problema, talvez nem você, não vão ter ganhos ou perdas com sua decisão, não estão comprometidos com seu resultado e muitas vezes nem sabem do que estão falando, por isso até podem dar um pitaco e indicar algo.

Em geral qualquer linguagem dará conta de qualquer coisa se o programador que está fazendo a aplicação sabe o que está fazendo. Se não souber, não é a linguagem que salvará o projeto, no máximo minimizará o problema.

Multi threading não é solução para tudo e existem outras soluções que conseguem dar o mesmo resultado. Por isso é preciso saber toda a computação para tomar a decisão correta.

Se acha que precisa criar threads em Python para atender a demanda, então a linguagem é errada. Python é uma linguagem que foi feita para ser mais lenta e a implementação atual é muito lenta. Se a pessoa optar por qualquer linguagem que costuma ter resultado mais eficiente em apenas uma thread, terá uma resultado melhor que Python com várias. Por isso essa discussão do GIL nunca fez sentido. Só faz sentido para quem quer teimosamente insistir na linguagem que não é adequada para aquilo. Ou é adequada com ou sem GIL.

Mas novamente, é só questão de arquitetura e colocar mais recursos de hardware. Se quer uma arquitetura mais simples e gastar menos com infra, então esqueça as linguagens de script.

Todas as outras mais conhecidas que rodam código nativamente, mesmo através de um JITter, e que provavelmente não tem abstrações caras, como a tipagem dinâmica, vão atender muito melhor. Qualquer uma delas e não terá diferenças brutais se a pessoa souber o que está fazendo.

Eu acho bastante curioso como muita gente ignora C# em várias situações, especialmente quando se fala em performance: https://www.techempower.com/benchmarks/#hw=ph&test=plaintext&section=data-r22.

O parágrafo quase no final com várias perguntas eu não vou comentar porque pra mim não faz sentido dentro do que eu sei sobre o problema (obviamente que pode fazer dentro de algum cenário real onde tem demanda pesada, não 30, se for milhões). Só acho que muita gente usa um monte de cacareco sem necessidade alguma e porque acha que não vai dar conta, ou porque ela sabe que fará um código muito ruim.

Muita gente só adota microsserviços e outras técnicas complexas e ineficientes porque ela não consegue fazer a aplicação corretamente. Para ter uma ideia, o Stack Overflow, que há pouco era um dos 30 sites mais acessados do mundo, rodava com um servidor quando queria (mantém outros para ter mais garantias), feito do jeito simples e indo contra o que quase todo mundo prega por aí. E em C#.

Faz sentido para você?

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Olá, antes de tudo, sou um mero júnior que vai tentar expor sua visão, talvez eu esteja equivocado em alguns pontos, então não leve isso como verdade absoluta.

Em primeiro lugar, o Fábio Akita está correto em sua colocação, de certa forma, a escolha da linguagem depende muito do contexto em que o projeto está inserido. Um projeto mal feito em Go não tem uma performance melhor do que um mal feito em PHP.

Outro ponto a ser discutido é sobre o design do sistema; desconsiderando totalmente a implementação, estudar a arquitetura do sistema é fundamental, visando sua evolução ao longo do tempo. Por exemplo:

• Faz sentido implementarmos uma lógica de filas em uma aplicação que recebe menos de 10 requisições por segundo?
• Talvez faça sentido, em alguns momentos, aumentarmos as instâncias das máquinas na AWS para suprir a alta demanda e reduzirmos essa quantidade em outros momentos, utilizando uma estratégia para distribuição de carga.
• Implementarmos uma estratégia de cache talvez reduza a interação do sistema com o banco de dados.
• Talvez, se alocarmos o sistema em uma máquina melhor, traga mais benefícios.
• E se de fato implementarmos um sistema de fila, com o RabbitMQ, vai melhorar?
• E se utilizarmos uma arquitetura orientada a eventos e afins? (Só divagando aqui agora)

O ponto que eu levantei com tudo isso é que, na discussão acima, eu não precisei falar de linguagem para discutirmos performance, escalabilidade, segurança, disponibilidade e outros pontos importantes para um sistema de qualidade.

Eu já desenvolvo sistemas a 16 anos e totalmente focado na web e banco de dados, sistemas SaaS, com muito pouco de processamento intenso em CPU.

A pergunta qual linguagem é melhor no quesito performance é a pergunta errada nesse caso. Já que vc citou o Akita, procura o vídeo dele comentado sobre o hackaton que o pessoal fez, tem poucos meses esse vídeo. Nesse hackaton, o pessoal tinha que montar um serviço e ganhava quem conseguisse entregar mais requisições por segundo (RPS). Quem ganhou no hackaton foi o C# se não engano. Mas como todos repositórios eram públicos, o pessoal continuou trabalhando nos projetos e todos os participantes conseguiram chegar mais ou menos no mesmo RPS. Ou seja, se vc não é o Twitter ou o Netflix, a performance não é um critério tão importante.

Por quê? Se sua requisição demora a retornar pq vc tem muito processamento rolando, o certo seria jogar a carga de trabalho em um fila, retornar o quanto antes a requisição inicial ao invés de deixar o cliente esperando e configurar um outro processo para dar vazão nessa fila (worker). Nesse caso, vc e o cliente tem que combinar uma forma de descobrir quando esse trabalho assíncrono é concluído. Pesquise no framework Laravel do PHP sobre queues, ali tem um exemplo desse fluxo que escrevi aqui.

Ou seja, o seu backend pode ser em qualquer linguagem, a mais confortável pro time ou a mais usada no mercado, com maior número de profissionais disponíveis. Os critérios são outros se vc delega o trabalho pesado pra uma fila.

Atuo no mercado corporativo a muitos anos, hoje dentro de banco. A linguagem de back ou front, banco de dados, nuvem, devops e toda tralha tecnologia de TI que temos vai depender de onde estamos, o quê está fazendo e quanto $$$ temos para investir. Na minha opinião, qualquer linguagem resolve um problema, mas contextualizando o pensamento, faça-se uma pergunta: vai desenvolver sozinho tudo ou terá um time? produto final ou MVP? vc vai desenhar/arquitetar o projeto ou só vai codar? Penso que a saída mais simples é a mais eficaz. Vai testar um produto, solo, nao tem grana nem time disponível, precisa fazer e ver o quê dá. Faça dentro do que domina. Deu certo, evolua, faça novas peças, veja se tem tecnologias, frameworks, serviços e afins dentro do quê domina para resolver os problemas que vão surigr, a performance, segurança e etc. Na minha opinião, cravar que linguagem x ou y é bala de prata pra tudo não existe. O fato é que tempo é dinheiro e toda hora aprender uma linguagem nova, até é legal, mas custa tempo, logo custa dinheiro. Dependendo da fase da vida que estiver, o valor do tempo dobra seu preço. se estive liderando um time, produto fibal e vai escalar, debata com time, veja a skill de cada um e pense: daqui alguns meses precisarei de um monte de dev? se sim, parta para aquilo que o mercado tem com mais abundância, pois vai impactar diretamente no seu custo de projeto. Modinha em grupos de TI não paga conta em proejto. Go, rust, lua e afins deve ser muito legal, mas empresas formam e contratam devs para seus produtos e que rege o mercado são os grandes, então digo que java, c# e javascript estão anos luz na frente, não pq são melhores ou mais eficientes, talvez até sejam, mas os players dominantes usam e possuem milhares de devs usando e atuabdo neste momento no mercado, e se vc precisar de muitos devs é desse mercado que terá de tirar. Referência de que EUA ou Europa usam x linguagem, pôde nao refletir nossa realidade.