Qual idioma - D, Go ou Rust tem melhores perspectivas de substituir C e por quê?

Apesar do meu status e óbvio viés como um dos criadores de D, tentarei responder francamente; Eu segui os caminhos de Go and Rust e sei absolutamente onde a roupa suja é lavada em D. Encorajo pessoas em posições semelhantes nas comunidades Rust and Go a compartilharem suas opiniões. Então aqui.

Para iniciantes, em algum lugar da pergunta deve aparecer C ++. Se ele deve ser substituído por C ou se é um dos candidatos à substituição de C, mas, de qualquer forma, o C ++ é um elemento-chave da equação. Este é o idioma mais próximo de C e um passo óbvio para a frente. Dada a idade de C ++, suponho ainda que C ++, juntamente com C, seja o objetivo da substituição.

Cada idioma possui uma série de vantagens fundamentais (eu as chamo de "uma vantagem de ordem de magnitude", a seguir denominada "bônus de 10x", uma vez que se qualificam na liga principal em relação às abordagens típicas) e vários problemas. O futuro desses idiomas e seu sucesso em eliminar o C dependem de como eles implementam estrategicamente seus bônus de 10x e como superar seus problemas.

Deixe-me livrar de D primeiro

Obviamente, esta é uma demonstração da minha própria casa, então sei para onde ir para mostrar adequadamente apenas o que é necessário e esconder os lugares sujos. Também posso falar mais sobre D do que o resto do par, pela simples razão de que o conheço muito melhor. Falando com franqueza bruta, os principais problemas de D são:

• Má recepção do público após muitos anos de existência nominal. Os fígados da comunidade podem criticar essa afirmação (D em sua forma atual é relativamente jovem, a popularidade está crescendo etc.). Mas essa atitude persiste e afeta o crescimento adicional da popularidade e isso é um fato. Como resultado, gerentes e engenheiros são céticos em relação à popularização de uma linguagem perdida há tanto tempo. Além disso, o tempo trabalha contra D até que não haja aumento óbvio na popularidade.
• A triste história de D relacionada à coleta de lixo (GC). O GC é uma grande invenção, mas a decisão de usá-lo em D isolou-o instantaneamente do público-alvo principal - programadores em C e C ++. Para eles, a fila da festa parecia “Não quer GC? Não tem problema! Você também pode usar D com RAII ou com controle manual! ” Apesar de, em geral, isso ser verdade, essa abordagem era praticamente inútil devido à falta de suporte para uma biblioteca padrão, o que significava que o usuário pretendido seria desbotado e começaria com a criação de uma infraestrutura básica. Mesmo para quem não se importava com o GC, a qualidade de sua implementação era bastante discreta. Em geral, podemos dizer que D obteve todas as deficiências do GC, mas não aproveitou.
• Falta histórica histórica de visionários. Privado de apoio corporativo, D liderou a comunidade, na qual é mais fácil encontrar um engenheiro astuto do que um gerente de projeto ou um líder carismático. Com o tempo, o sucesso dos esforços de D em promoção e autopromoção teve um resultado negativo. O primeiro documento de planejamento é datado de 1º de janeiro de 2015 e a próxima iteração (Vision / 2015H2 - D Wiki) saiu quatro meses depois do planejado, o que é um ótimo exemplo de auto-ironia em termos de planejamento

Havia, é claro, outros problemas, mas eles eram uma consequência do exposto acima ou tinham consequências muito menores.

Eu acho que os bônus de 10x para D são os seguintes (mais uma vez, quando digo 10 vezes, isso é coloquial "melhor por uma ordem"):

• Em 10x, a compilação é mais rápida que o C ++ para código comparável. Esse buraco não pode ser fundamentalmente fechado em C ++, e é extremamente difícil saltar em qualquer outro idioma. (Ir compila um pouco mais rápido que D, mas o código resultante é mais lento) A experiência de usar uma linguagem de sistema que compila tão rapidamente em código rápido é transformadora de práticas antigas e muito promissora. Combinado com o poder das abstrações em D, isso torna D uma boa opção para escrever código altamente otimizado pela simples razão de que a experimentação é barata.
• 10x mais rápido que as linguagens de script com comodidades comparáveis. D é adequado para scripts de tarefas diárias. O ciclo de compilação / lançamento permanece tão rápido quanto os benefícios em velocidade são imensos. Além disso, não há problema em "correr para os limites" - se o script se tornar grande, em D sempre haverá ferramentas de linguagem e modularidade suficientes. É claro que há uma mosca na pomada; por exemplo, no Python, existem muito mais bibliotecas prontas. Mas o bônus de 10x é fundamental aqui - as linguagens de sistema não têm tanto açúcar sintático, e as linguagens de script estão irremediavelmente atrasadas.
• 10x é mais fácil de integrar com C e C ++ do que qualquer outro idioma. D usa as mesmas estruturas na memória que C e C ++; e cria sobre eles, mas a leitura das camadas subjacentes permanece livre em termos de velocidade. A biblioteca C padrão é totalmente acessível, sem penalidades - nem em velocidade nem em sintaxe, e embora algumas melhorias sejam necessárias para uma simplicidade semelhante em termos da biblioteca C ++, muitas bibliotecas C já estão disponíveis (https://github.com/D- Programação ...). Pode-se afirmar literalmente que nenhum outro idioma pode atingir esse nível de integração.
• 10 vezes melhor do que qualquer outra linguagem do sistema em genéricos e metaprogramação. Em D, introspecção estática, computação em tempo de compilação (CTFE) e geração de código baseada em mixina (mistura de código) compõem o coquetel Molotov, que é muito difícil de misturar corretamente em outros idiomas, nem novos nem sobreviventes; neste jogo, o Go é tão louco que nem sequer corta um pedaço; C ++ 17 está irremediavelmente perdido em uma floresta escura; e Rust está apenas tentando balbuciar.

Ir para Ir

Devo enfatizar que essa é apenas a minha opinião, no entanto, merece sua atenção. Os problemas de Go são os seguintes:

• Desaceleração fundamental devido a chamadas indiretas e o coletor de lixo (GC). Quase nenhum aplicativo Go significativo pode ser gravado sem o recurso a chamadas indiretas e GC, que são a funcionalidade central. Essas são as principais barreiras ao desempenho do núcleo Go. A resposta de Go foi principalmente tática - por exemplo, melhorando o desempenho do GC. No entanto, é improvável que vença o desafio de substituir C taticamente.
• Política. A linha partidária da Go é desproporcionalmente forte e difícil em várias questões, pequenas e grandes. Um exemplo de um grande problema é que a abordagem aos genéricos era tão sem sentido e implacável que transformou os genéricos na palavra com a letra "G"; todo o tópico se transformou em lágrimas de sangue, dificultando qualquer tentativa de estabelecer um diálogo construtivo. Penso que politizar questões técnicas a longo prazo é um modelo extremamente prejudicial, e espero que o Go encontre uma maneira de consertar isso.
• Simplicidade é pior que roubo. Ir é muito simples (trocadilho, vai - anda, nota) - há até piadas sobre isso. No entanto, com o tempo, isso se torna problemático; O código Go é irremediavelmente pedestre - os codificadores Go encontram-se escrevendo repetidamente as mesmas coisas do ponto de vista de uma formiga, porque o Go não pode abstrair nem mesmo os conceitos ou algoritmos mais simples. Conceitos que ainda não foram implementados pelas bibliotecas de integração são difíceis de implementar. Há uma reação negativa dos programadores que usaram o Go para um projeto e não querem mais usá-lo novamente. Seria bom se a Go melhorasse a vida de clientes comuns.

Go 10x bônus na minha percepção são os seguintes:

• 10x em habilidade Estratégia. Após um breve período em que o Go foi posicionado como idioma do sistema, foi decidido posicioná-lo para serviços de rede. Foi uma grande jogada de marketing que aproveitou os pontos fortes da equipe Go (alguns dos melhores engenheiros de serviços de rede do mundo). Este é um mercado muito quente e o Go se tornou uma lufada de ar fresco para o mundo, que antes era dominado pelo Java EE, com sua burocracia e linguagens de script lentas. O Now Go é o principal jogador nesta área e será difícil de se mover.
• 10x na habilidade Engenharia. A Go possui uma forte equipe de engenheiros, e esse é o principal fator que influencia a qualidade da linguagem, em particular a biblioteca de rede e o conjunto de ferramentas. Até agora, uma boa engenharia compensou totalmente a fraqueza da linguagem.
• 10x em habilidade Branding. Muitos de nós estão prontos para admitir que o principal motivador para o uso do Go é sua conexão com o Google. Isso lhe dá autoridade de profissionalismo, qualidade e estabilidade. Obviamente, uma marca não é tudo, mas já faz do Go uma linguagem digna; ele não deveria ser fantasticamente bom. A marca fará o resto.

Por último, mas não menos importante, Rust

Deixe-me lembrá-lo novamente que esta é apenas minha opinião. Eu acho que Rust está enfrentando alguns problemas interessantes:

• Personalidade desarmônica. Depois de ler uma certa quantidade de código de ferrugem, aparecem histórias como "Cara perdia dias de pernas balançando", ilustradas por quadrinhos com pessoas com um tronco e pernas cruzadas (aprox. Tradução. Em russo, "Colosso nos pés de barro", mas impreciso) O gerenciamento preciso e seguro da memória vem em primeiro lugar e representa o centro do mundo. De repente, isso raramente é uma área problemática, o que leva ao fato de que uma grande proporção de planejamento e codificação é dedicada, de fato, ao trabalho administrativo (que linguagens com o GC automatizam sem olhar). A reutilização segura e predefinida da memória é uma tarefa séria, mas não a única ou pelo menos não a mais importante do programa. Como resultado, o Rust gasta uma quantidade desproporcional de recursos de design de linguagem nisso. Seria interessante ver como Rust incha para outros aspectos da linguagem; a única opção é expandir o idioma, mas a questão é quanta abstração pode ajudar com a desagradável necessidade de controlar recursos em todos os níveis.
• Sintaxe estrangeira. A sintaxe de Rust é diferente [de todos], mas não há vantagem óbvia nesse exotismo. Isso irrita as pessoas que vêm de idiomas da família Algol, que precisam lidar com uma sintaxe radicalmente diferente, além da necessidade de gerenciar manualmente toda a contabilidade com recursos.

Os bônus de 10x da Rust são:

• 10 vezes os melhores teóricos. Desses três, apenas Rust possui teóricos de classe mundial no desenvolvimento de uma linguagem de codificação. Isso pode ser visto na precisão da descrição técnica do idioma e nas profundezas da abordagem técnica.
• 10x mais segurança do que outros idiomas do sistema. Claro, isso deve estar aqui, só podemos debater o custo dessa abordagem.
• 10 vezes o melhor PR (PR, publicidade, aprox. Por.) Houve um período bastante longo em que Rust era o favorito da comunidade, o que não podia ser confundido: por qualquer problema, Rust tinha uma solução ou precisou obtê-la com o lançamento da versão 1.0. A realidade do lançamento do 1.0 interrompeu essa lua de mel e foi marcada (nas minhas medidas e expectativas) por uma acentuada diminuição do interesse geral, embora esses fatores tendam a se prolongar. Além disso, no final, Rust é uma linguagem decente com realizações reais e está bem posicionada para transformar esse hype prolongado em um mercado estável.

Brevemente

Se uma dessas linguagens é capaz de substituir gradualmente C, C ++ ou ambas as linguagens nos sistemas de software existentes, e se essas linguagens se tornarão prioridade para projetos que hoje escolhem C ou C ++ por padrão, tudo depende da capacidade dessas linguagens usarem. suas vantagens e encontre soluções criativas para seus respectivos problemas.

Nota tradutor.
Desculpe pelo artigo antigo, eu o encontrei no final da minha série sobre programação confiável e parecia divertido o suficiente para citar. No RuNet, no entanto, uma tradução e, de fato, uma discussão completa, não foi encontrada.