Um bom teste para a eficiência de conversão de um compilador é a autocompilação: quanto tempo leva um determinado compilador para se compilar? Para C ++, leva muito tempo (horas?). Em comparação, um compilador Pascal / Modula-2 / Oberon se compilaria em menos de um segundo em uma máquina moderna [1].
O Go foi inspirado por esses idiomas, mas algumas das principais razões para essa eficiência incluem:
Uma sintaxe claramente definida que é matematicamente sólida, para varredura e análise eficientes.
Uma linguagem com segurança de tipo e estaticamente compilada que usa compilação separada com verificação de dependência e tipo através dos limites do módulo, para evitar a leitura desnecessária de arquivos de cabeçalho e a compilação de outros módulos - em oposição à compilação independente , como em C / C ++, em que nenhuma verificação entre módulos é executada pelo compilador (daí a necessidade de reler todos esses arquivos de cabeçalho repetidas vezes, mesmo para um programa simples de uma linha "olá mundo").
Uma implementação eficiente do compilador (por exemplo, análise de cima para baixo de passagem única e descida recursiva) - que obviamente é bastante auxiliada pelos pontos 1 e 2 acima.
Esses princípios já foram conhecidos e totalmente implementados nas décadas de 1970 e 1980 em idiomas como Mesa, Ada, Modula-2 / Oberon e vários outros, e só agora (na década de 2010) estão chegando a idiomas modernos como Go (Google) , Swift (Apple), C # (Microsoft) e vários outros.
Vamos torcer para que em breve essa seja a norma e não a exceção. Para chegar lá, duas coisas precisam acontecer:
Primeiro, os fornecedores de plataformas de software como Google, Microsoft e Apple devem começar incentivando os desenvolvedores de aplicativos a usar a nova metodologia de compilação, permitindo que eles reutilizem sua base de códigos existente. É isso que a Apple agora está tentando fazer com a linguagem de programação Swift, que pode coexistir com o Objective-C (já que ele usa o mesmo ambiente de tempo de execução).
Segundo, as próprias plataformas de software subjacentes devem ser reescritas ao longo do tempo usando esses princípios, ao mesmo tempo em que redesenham a hierarquia do módulo no processo para torná-las menos monolíticas. Obviamente, essa é uma tarefa gigantesca e pode levar a maior parte de uma década (se tiverem coragem suficiente para fazê-la - o que não tenho certeza no caso do Google).
De qualquer forma, é a plataforma que impulsiona a adoção do idioma, e não o contrário.
Referências:
[1] http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf , página 6: "O compilador se compila em aproximadamente 3 segundos". Esta citação é para uma placa de desenvolvimento Xilinx Spartan-3 FPGA de baixo custo, funcionando com uma frequência de clock de 25 MHz e apresentando 1 MByte de memória principal. Com isso, pode- se extrapolar facilmente para "menos de 1 segundo" para um processador moderno executando em uma freqüência de clock bem acima de 1 GHz e vários GBytes de memória principal (ou seja, várias ordens de magnitude mais poderosas que a placa FPil Xilinx Spartan-3), mesmo ao levar em consideração as velocidades de E / S. Já em 1990, quando o Oberon era executado em um processador NS32X32 de 25MHz com 2-4 MBytes de memória principal, o compilador se compilou em apenas alguns segundos. A noção de realmente esperarpara o compilador terminar um ciclo de compilação era completamente desconhecido para os programadores de Oberon naquela época. Para programas típicos, sempre levava mais tempo para remover o dedo do botão do mouse que acionava o comando de compilação do que aguardar o compilador concluir a compilação que acabou de ser acionada. Foi uma gratificação verdadeiramente instantânea, com tempos de espera próximos de zero. E a qualidade do código produzido, apesar de nem sempre estar totalmente a par dos melhores compiladores disponíveis na época, era notavelmente boa para a maioria das tarefas e bastante aceitável em geral.