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

Obrigado pela contribuição, @lgcovizzi! Gostaria de tecer alguns comentários. Seu feedback é muito bem-vindo! :)

Vamos lá...

Você diz que um código utilizando OOP tende a ser complexo, tendo em vista que você precisa ter conhecimento em diversas boas práticas e padrões de projeto, enquanto um código mais procedural não sofre desses problemas.
Sinceramente? Essa complexidade me parece estar muito mais relacionado ao escopo do projeto do que ao paradigma utilizado. Se você está desenvolvendo um projeto grande e complexo, não importa o paradigma que você prefere, você PRECISA saber boas práticas em ambos os casos para 1) não fazer bagunça; 2) criar componentes reutilizáveis e; 3) criar um código seguro e testável. Portanto não importa o paradigma, para chegar num nível de excelência, a pessoa precisa estudar e lidar com diferentes projetos durante anos.
Mas e se projeto for simples? Ué, dá pra fazer um código simples com OOP também! O problema é que as pessoas quando aprendem as boas práticas começam a querer encaixar em tudo, mas tá errado.

Um outro ponto é sobre a ascenção de linguagens que não adotaram o paradigma de OOP. Cara, primeiro que as linguagens que você citou nem tem o objetivo de concorrer com .NET ou Java, tendo em vista que são tecnologias que atuam em mercados muito diferentes. A única semelhança que eu consigo enxergar é na criação de serviços para servidores, na qual o ASP.NET não fica muito atrás não. Não é porque Go consome menos recurso (uma vez que não tem um GC) que isso irá necessariamente se traduzir em performance bruta. Justamente pelo fato do C# compilar para o .NET Runtime, é possível realizar otimizações que um programa 100% compilado para machine code não conseguiria, já que ele não consegue "observar" como a sua aplicação está rodando durante a execução. Não atoa a cada release do .NET sempre tem uma seção dedicada as otimizações. E mesmo que você queira muito que o seu programa seja compilado para assembly nativo da CPU, desde do ASP.NET 8 é possível compilar os serviços usando um AOT compiler. Será mesmo que a hegemonia dessas linguagens está ameaça? Olha, eu acho que não. Isso porque eu não entrei na questão do ecossistema e do tooling dessas linguagens, que são pontos que não devem ser ignorados.

Eu acho excelente ter ferramentas especializadas, porque com isso obtemos a capacidade de criar projetos melhores. Mas falar em fim da hegemonia? Acho um pouco sensacionalista haha.

Carregando publicação patrocinada...
2

Fora o 0.x% dos programdores do topo, os projetos que eu vejo por aí as pessoas não sabem fazer componentes reutilizáveis, isso vale para a esmagadora maioria dos sêniors CTO, etc. A maioria começou aprender a programar nos anos 90 ou depois quando se começou ensinar a programar de forma equivocada, com nase em projetos quer a maioria nunca faria, e as pessoas apassaram adotar complexidade sem ganho ou ficar fazendo repetidas vezes as mesmas coisas, por isso usam coisas em camadas que se você precisa mudar um campo, precisa mexer em pelo menos 3 lugares diferentes e as pessoas acham isso normal. Ficam gastando montanhas de horas/homem fazendo CRUDs.

Muito códigos são bagunçados justamente porque seguem "boas práticas", que são horríveis se a pessoa não entende oque está por trás delas, Quanto mais eu vejo as pessoas falando em boas práticas mais os códigos ficam piores, porque estão seguindo receitas de bolo em vez de estudar a computação como um todo.

Inclusive boa parte do código OOP que é criado não traz vantagens que poderiam existir, porque a pessoa nem entende oque está fazendo. Isso precisa mudar. Mas primeiro a pessoa precisa reconhecer que faz errrado, e isso não está acontecendo. As pessoas sequer entendem que OOP é para gerenciar complexidade. E acham que não tem jeito de fazer código organizado sem ela. Como exemplo, talvez a maior base de código do mundo não passa nem perto de OOP, até por ser feito em C, todo mundo põe a mão e funciona maravilhosavamente bem. É clar oque tem a vantagem que só programador bom põe a mão, quando os programadores não são tão bons, começa ter que usar mecanismo para gerenciar a bagunça que eles fazem.

Go possue GC sim, e apesar de ser bom em um certo padrão, ele é menos sofisticado que o do .NET ou alguns da JVM, que provavelmente são os melhores do mercado, ainda mais os pagos para terceiros (que alguns zoam que é porque Java gera muito lixo e se ele tivesse GC mesmo quando o código terminasse de executar ele seria engolido pelo GC :D :D :D). Go consegue aqui e ali, não em tudo ser um pouco mais rápido por causa da forma como lida com corrotinas e porque tem uma biblioteca um pouco mais pensada para sistemas e não aplicação enterprise. Algumas abstrações custosas a menos na linguagem ajudam um pouco também. Fora isso também é a cultura. Por enquanto a maioria dos programadores Go costumam ser um pouco melhores, mas está mudando e logo terão hordas de programadores ruins como tem em C#, Java, Python, PHP, JS, etc.

Essa coisa do JITter poder dar mais performance tem um fundo de verdade mas na prátrica o grande ganho foi quando o .NET começou ter AOT e PGO, é muito difícil dar essa performance tyeórica que o JITter seria capaz e gera um outro custo. O JITter pode dar algum ganho maior pontualmente, mas está cada vez mais raro.

De fato não dá muito para comparar as linguagens que ele comparou, e cada um terá seu segmento forte, mas o foco dele é que OOP não é tão necessário assim e as linguagens mais modernas estão se afastando disso, da mesma forma que estão abandonando exceções, que foi outra coisa errada que inventaram.

1