Antes que digam que sou contra Go, eu programo em Go, mas lendo friamente o texto, concluo que falta muito pra ser considerando um texto imparcial e completo.
Está faltando falar, ou falta profundidade sobre:
- Escrever código acoplado e hierárquico não é inerente ao paradgma, e sim uma escolha de quem escreve o código, é possível tomar a mesma decisão em outras linguagens;
- As pessoas incluiem comumente dependências que nunca vão usar, deixando a aplicação final mais lenta do que o necessário, comumento esse programador costuma não entender como funciona os detalhes da linguagem, novamente é uma decisão e não algo inerente ao paradmga;
- Código compilado nativo, mesmo escrito em linguagem OO costumam ter performance e consumo de memória reduzidos;
- Paradgmas não bloqueantes (Netty.io, Akka que roda sobre a JVM Java), que pode ser utilizado tanto em linguagem OO ou não OO
- No benchmark que compara a performance de algumas das aplicações mais importantes, não vemos dominância de uma linguagem ou paradigma;
- O Modelo de Atores, estude sobre Scala, muito bem implmentado performático com baixo uso de memória existem em JAva;
- Modelo de Multi Event Loop (Vert.X) disponível em vários paradigmas inclusive no OO (Java), escolha que junto com o paradgma reativo e não bloqueante melhora muito a performance, já que muito da lentidão está no código que bloqueia a thread;
- Imutabilidade, outro recurso independente de paradgma, escolha que melhora muito a performance, mas que comumento é ignorado por quem escreve o código;
- Reflection, ou introspecção recurso que as pessoas utilizam sem saber, mas existe opções de não fazer uso dele, infelizmente, em busca de entregas mais rápidas as pessoas são levadas a fazer uso por comodidade muitas vezes sem saber o que é os impactos, novamente essa é uma escolha e não é inerente ao paradgma OO já que existe em outras linguagens não OO;
- Paralelismo, utilizar ou não é uma escolha indpendente de OO, mas é comum escolherem escrever código que é executado sequencialmente mesmo que possa ser em paralelo;
Também senti falta de falar dos trade-offs, ou colaterais inesperado ao trocar o paradgma ou linguagem.
Colocar o Bend como link depois de toda essa argumentação me soou incoerente, digo isso porque o Bend pega um nicho muito específico e melhora performance apenas para aquele nicho, outros tipos de algoritimos não consegue obter benefícios ao adotar ele. Detalhe, o próprio autor já declarou publicamente que escolheu pra linguagem uma sintaxe como a do Python, mas admite que deveria ter escolhido uma sintaxe diferente que seja mais expressiva pros novos conceitos que o Bend trás.
"...princípios como SOLID, padrões de projeto e técnicas avançadas de refatoração", não é excluvido do paradgma OO, esse é um conhecimento necessário em qualquer paradgma.
Bem, vou parar por aqui, mas gostaria de sugerir a leitura do livro: Um livro ilustrado de maus argumentos
OOP incentiva um certo acomplamento, se a pessoa não faz, ótimo, mas ela está se afastando do paradigma. E se ela evita a hierarquia, que pode ser boa em alguns casos, ela está abandonando o paradigma, porque herança é o único mecanismo que só OO tem.
É fato que o maiuor problema é o programador do que o paradigma, mas ele contribui para a pessoa ser assim, e ele existe para as pessoas que são assim. Os melhores programadoes não precisam de OO para ajudá-lo se organizar. Quem precisa disso é o medíocre. O ruim nada salva.
OO de fato não adicionar muito custo de processamento e consumo de memória, mas nao é custo zero. Tem muitas outras coisas que contam absurdamente mais, incluindo a capacidade de otimização do compilador e/ou runtime, algumas outras features da linguagem, o jeito que a pessoa programa e como é o gerenciamento de memória ou a qualidade do GC e o viés que ele busca mais.
OO é um paradigma secundário, como tantos outros, e eles não são escludentes, só os raros primários são excludentes, e mesmo assim dá para ter alguns mecanismos de um em outro, mas não o todo.
Imutabilidade dificilmente melhora a performance, a não ser quando facilita a vida do criador do GC (se imutável seja obrigatório). Tem casos, mas o que acontece mais é na verdade degradação de performance por imutabilidade, pouca, mas acotece porque cópias passam ser necessárias onde a mutabilidade evitaria. E o grosso dos programadores não se atentam a isso, até porque geralmente não precisam que tenha a melhor performance. Tem padrões que fazem o GC trabalhar absurdamente mais.
As pessoas sequer entendem o que é design patterns, eu botei link em outro comentário meu aqui na página. SOLID é só um nome bonitinho para falar sobre coesão e acoplamento.
O texto de fato é incompleto e falho, mas é uma boa base para gerar alguns debates. Msmo sendo imperfeito ele criou conteúdo relevante aqui mais do que a soma de vários outros nos últimos dias somados. Seu texto ajudou muito nisso, então a missão dele está cumprida.
Eu já conhecia os "maus argumentos", mas obrigado por esse livro que sempre ajuda fixar melhor ou aprender sob outro ângulo.