Falar q não presta é forte demais, mas tb não gosto.

Sobre ponto de performance em específico: Concordo, geralmente na maioria dos casos de uso, não são os milhões de TPS a mais q um .net da vida tem nos benchmarks que farão a diferença real.

Geralmente a maior parte das lentidão de software corporativo estão no tempo de espera de serviços externos (dbs, cache, apis, arquivos, etc), do q em processamento bruto. Embora performance de Python me incomode, não uso isso como muleta pra não usar.

Sobre "capacidade de se conectar com tudo que você precisa para construir soluções completas."
Isso é o básico, qualquer linguagem q se preze oferece isso. Sem isso já estariam mortas de verdade. Não considero isso um ponto positivo válido na análise.

Sobre popularidade
Popular sim, mas popularidade não siginifica ser bom, significa apenas que caiu no gosto popular - se as pessoas são qualificadas pra analisar se é bom, ou se estão apenas seguindo a manada, é outra história. Muita coisa ruim é popular - músicas, filmes, programas de tv, e tecnologias tb.

Mas acho q a simplicidade de criar um script, instalar pacotes e executar; aliado a baixa verbosidade de codificação, foram fatores importantes, válidos e realmente bons para o aumento da popularidade.

Issi colaborou pra ser uma porta de entrada no ensino de programação, e contribuiu muito pra popularidade.

Agora, meus pontos sobre não gostar
Venho de paradigmas orientado a objetos e tipagens fortes (C# como principal lang). Meu primeiro contato com Python foi por volta de 2010 pra aprendizado, fiz uns cursos, e na época não gostei. Depois no decorrer da vida, só pra coisas simples, como lambas, pequenas automações e pipelines. Agora recentemente começei um projeto Python devido a frameworks de Gen IA onde ele está realmente a frente das outras langs. Dessa vez criando um sistema corporativo, com perspectiva de uso por 5k de users únicos por dia, e 20k mensal em média. Minha opinião atualizada: Achei uma experiência de desenvolvimento horrível.

Meus pontos:

• Tipagem fraca pode ser bom pra início, mas se torna facilmente um incômodo (mesma treta do js). Problemas q pegariamos em tempo de build, só aparecem em tempo de execução ou no teste automatizado se cobrir tudo (q é muito trampo). Isso força mais nossa cognição no dia a dia.
• Intellisense infere muita coisa q não funciona devido ao problema de tipagem, e novamente, só vemos em tempo de execução.
  • Exemplo: Um método q recebe um argumento tipado, mas um dos locais q chama manda um dict por engano, e outro local manda o objeto. Isso funciona, mas dependendo das funções utilizadas internamente, pode dar erro.
• Mutação da estrutura de classes: Isso de permitir definir/excluir atributos dinamicamente no objetos além dos definidos na classe é um ponto periogoso para desorganização.
• Lentidão para startup de projeto em debug: lentidão pra iniciar o projeto FastAPI em modo debug é irritante no dia a dia - Não sei se é coisa do meu setup, mas percebi a lentidão a partir do momento q começei a usar fastapi.
• Muito dos benefícios q muita gente exalta, não passam de wrappers em cima de outros projetos compilados nativamente para o SO; e, q na maioria dos casos tb possuem wrappers para outras linguagens (ex.: tesseract para ocr, opencv para imagens, sphinix para audio, etc..). Sendo, os ports das langs fortemente tipadas mais intuivos de usar.
• Muito sobre a baixa verbosidade tb exaltada como benefício, no fim são design de classes e libraries, não méritos sintático da linguagem.
• Embora performance bruta não seja meu principal fator, o mal suporte a mutli-tread, não aproveitando arquitetura de cpu multi-core de hoje em dia, é um forte ponto contra. Nao digo nem pra um processamento bruto de um job pesado em cpu, mas para performace várias pequenas coisas paralelas em ambientes de alta concorrência. Isso pode afetar bem o workload.
• Outra coisa q me incomoda bastante é o gerenciador de dependências muito fraco. O pip install adiciona pacotes ao ambiente global, e não ao projeto. Então o dev desavisado atualiza um pacote em outro projeto, e tem impacto global. Depois esquece de atualizar o requerements.txt. Tb não há uma boa experiência para salvar novos pacotes no requerements.txt. Sei dos ambientes virtuais do pyenv/venv pra resolver conflitos, mas em geral, é uma estrutura arcaica, e que demanda outro aprendizado extra (aqui aquela facilidade inicial do contato com a linguagem, começa a se complicar). Outros gerenciadores de pacotes e build como nuget, mavem, gradle já resolvem de forma melhor e intuitiva.
• Mal planejamento de retrocompatibilidade: Quem é mais velho provavelmente tem um rancor guardado das breaking changes das versões 2.7 pra 3.x kkkk.
• Também senti falta de "syntax sugars" como:
  • operadores ternários (fáceis de concatenar várias operações)
  • colaescing operator
  • pattern match um pouco verboso pra condições complexas.

E, pra falar uma coisa boa q gostei: Curti o conceito de "union" pra informar que um argumento pode assumir N tipos de dados diferentes. E, estou pensando se considero falta de overload de métodos como algo ruim, ou se union vai me fazer não achar isso incômodo.

Pra finalizar: Como dev, gosto de contratos fortes, explícitos, q deixam claro o propósito do desenvolvimento, e evitam desvios acidentais. Digitar mais código por isso não é um malefício na minha filosofia - e, apenas se muletar em cima de verbosidade de código pra dar hate na lang, tb é apenas uma visão míope da situação.

#paz kkkk