Executando verificação de segurança...
2

Eterna dúvida sobre linguagens para back-end

Olá, eu tenho uma dúvida que por muito tempo fiquei tentando achar uma resposta definitiva.

Vou apresentar um pouco do meu background. Sou formado em Engenharia Elétrica e atuo desde 2020 como Gerente de Projetos em uma empresa de P&D (Pesquisa e Desenvolvimento) na área de Inteligência Artificial.

Na graduação eu aprendi o básico do básico de C++ e Python. No meu trabalho consegui aprender bem mais sobre C++ e Python. Nós éramos muito bons em desenvolver o software "bruto", digo nós porque a empresa é formada por 2 sócios que são meus amigos e todo o pessoal mais antigo é amigo também (embora certas horas a gente quer matar um ao outro rsrs).

Por software "bruto" eu me refiro ao software sem estar conectado a um banco de dados, não havia interface gráfica e nem nada do tipo. Basicamente era um executável que abria uma janela da OpenCV rodando o que o cliente queria com alguns desenhos que a gente fazia. A gente focava bastante em desenvolver para hardwares de baixo poder computacional, celulares, AI-Box (computadores dedicados) da Qualcomm e NVIDIA.

Mais pra frente, a gente pegou um projeto que forçou a gente a fazer esse software "bruto" se comunicar com um back-end e este back-end se comunicar com um front-end. Não sabia de nada, mas eu sabia que a linguagem para ambas as partes era basicamente JavaScript. Posteriormente descobri que Python possui uma "Micro-Framework" chamada Flask e, mais recentemente, descobrimos o FastAPI que é uma Framework bem bacana para trabalhar com back-end.

Durante essa etapa de aprendizagem, eu fui ler sobre o que era usado na indústria por grandes players. Eis que eu descobri outras linguagens, Go e Rust, além do JavaScript.

Percebi que existiam diversos pacotes para trabalhar com Web em cada linguagem:

  • GoLang: Gin-Gonic
  • Rust: Rocket
  • Ruby: Rails
  • Python: Flask/FastAPI
  • C++: Crown e Drogon
  • JavaScript: Express/Fastify, não tenho certeza mas talvez Next.js?
  • Java com SpringBoot.

E diante de tudo isso eu fiz a famosa pergunta:

  • O que é melhor usar?

Eu fui em busca da resposta para essa pergunta em diversos lugares, mas nunca havia algo muito conclusivo, pois cada um falava uma coisa diferente.

O que eu percebi, vendo principalmente os vídeos do Fabio Akita, é que tudo depende do contexto em que seu projeto se encontra e, além disso, como você estrutura seu back-end.

Atualmente, na onde eu trabalho desde 2019, a gente utiliza FastAPI por dois motivos:

  • Facilidade de uso, teste e deploy no Heroku.
  • Facilidade de desenvolver, pois 100% da empresa trabalha com Python.

Mas ainda não tivemos casos em que:

  • há um grande número de usuários acessando simultaneamente.
  • o processamento do back-end é bem intenso.
  • há uma junção dos dois itens acima.

Embora eu não seja tão fã de Python devido ao Global Interpreter Lock (GIL), eu vejo que, talvez, uma possibilidade fosse utilizar Go/Rust/C++ para desenvolver um back-end onde eu precise usar de multi-threading para lidar com as várias requisições e meu processamento é intenso.

Mas uma das minhas perguntas são: será que só isso resolve? Eu acredito que deva existir alguma coisa que está faltando no meu conhecimento que eu não entenda ainda. Por exemplo: o que aconteceria se eu receber 30 requests simultâneos e meu back-end só processar 10, onde os outros 20 vão parar? Eu acredito que no lixo e meu back-end não vai processar eles. Ai vendo por esse lado, eu precisaria de um sistema de fila? Usar o Kafka/SQS da AWS?

Dado todo esse texto, minha pergunta é:

Em qual momento que a escolha da linguagem de programação se torna um diferencial na minha aplicação?

Carregando publicação patrocinada...
3

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).

2

Sim faz sentido sim, de fato você falou o que eu achava há um tempo, mas precisava de alguém com mais propriedade para firmar, pois eu não confio muito em mim nessa área.

Quando você diz:

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.

Você se refere a usar linguagens compiladas, como Rust, Go, C# (acredito que C# seja compilado, nunca usei), C++, Java (acho que Java também é compilado)?

2

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.

2

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.

2

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.