Хорошим тестом на эффективность перевода компилятора является самокомпиляция: сколько времени требуется компилятору для компиляции? Для C ++ это занимает очень много времени (часов?). Для сравнения, компилятор Pascal / Modula-2 / Oberon скомпилирует себя менее чем за одну секунду на современной машине [1].
Go был вдохновлен этими языками, но некоторые из основных причин такой эффективности включают:
Четко определенный синтаксис, который математически обоснован, для эффективного сканирования и анализа.
Типобезопасный и статически скомпилированный язык, который использует отдельную компиляцию с зависимостями и проверкой типов через границы модуля, чтобы избежать ненужных -читание заголовочных файлов и перекомпиляция других модулей - в отличие от независимой компиляции, как в C / C ++, где компилятором не выполняются такие межмодульные проверки (отсюда необходимость перечитывать все эти заголовочные файлы снова и снова, даже для простой однострочной программы "hello world").
Эффективная реализация компилятора (например, однопроходный синтаксический анализ с рекурсивным спуском сверху вниз), чему, конечно, очень помогают пункты 1 и 2 выше.
Эти принципы уже были известны и в полной мере реализованы в 1970-х и 1980-х годах на таких языках, как Mesa, Ada, Modula-2 / Oberon и некоторых других, и только сейчас (в 2010-х) находят свой путь в современные языки, такие как Go (Google), Swift (Apple), C # (Microsoft) и несколько других.
Будем надеяться, что это скоро станет нормой, а не исключением. Чтобы попасть туда, должны произойти две вещи:
Во-первых, поставщики программных платформ, такие как Google, Microsoft и Apple, должны начать с поощрения разработчиков приложений использовать новую методологию компиляции, позволяя им повторно использовать существующую кодовую базу. Это то, что Apple сейчас пытается сделать с языком программирования Swift, который может сосуществовать с Objective-C (поскольку он использует ту же среду выполнения).
Во-вторых, сами базовые программные платформы со временем должны быть переписаны с использованием этих принципов, одновременно изменяя иерархию модулей в процессе, чтобы сделать их менее монолитными. Это, конечно, гигантская задача, которая может занять большую часть десятилетия (если они достаточно смелы, чтобы на самом деле это сделать - в чем я не уверен в случае с Google).
В любом случае, именно платформа стимулирует принятие языка, а не наоборот.
Ссылки
[1] http://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf, стр. 6: «Компилятор компилируется примерно за 3 секунды». Это предложение относится к недорогой плате разработки Xilinx Spartan-3 FPGA, работающей на тактовой частоте 25 МГц и имеющей 1 МБайт основной памяти. Из этого можно легко экстраполировать до «менее 1 секунды» для современного процессора, работающего на тактовой частоте значительно выше 1 ГГц, и нескольких Гбайт основной памяти (т.е. на несколько порядков более мощных, чем Xilinx Spartan). -3 плата ПЛИС), даже с учетом скоростей ввода / вывода. Уже в 1990 году, когда Oberon работал на 25-МГц процессоре NS32X32 с 2-4 МБ основной памяти, компилятор скомпилировал себя всего за несколько секунд. Идея ожидания для компилятора, чтобы завершить цикл компиляции, была полностью неизвестна программистам Oberon даже тогда. Для типичных программ всегда требовалось больше времени, чтобы убрать палец с кнопки мыши, которая вызвала команду компиляции, чем ждать, пока компилятор завершит компиляцию, только что запущенную. Это было действительно мгновенное удовлетворение с почти нулевым временем ожидания. И качество созданного кода, хотя и не всегда полностью на уровне лучших на тот момент компиляторов, было удивительно хорошим для большинства задач и в целом вполне приемлемым.