Я могу себе представить, что даже идею SSA-модуля поначалу авторы Go могли воспринять в штыки :)

На самом деле все не так плохо в среднем. Просто тот пример очень синтетический и надеманный. Вот более реальное сравнение скорости компиляции разных ЯП в том числе  Go и Rust:
https://imgur.com/a/jQUav

Сейчас бы мерять скорость компиляции по одной бессмысленной ф-ции с непонятной арифметикой

тоже самое что мерять 1млн println c hello world

Вообще компиляторщики любят такое - чтобы была арифметика, байты, сдвиги и всё это бенчмаркать и чтобы оптимизации сверху.
никому не интересно бенчмаркать реальный код с объектами, веб реквестами

У Rust есть ктати один фатальный недостаток (как мне сказали недавно) и которого оказывается нету в Clang. Ну во первых это MIR, который много отжирает памти, ну а во вторых это отсутсвие мемоизации AST поддеревьев

Проблема в том, что "единая мат. нотация" есть только в голове у Гая. В мире - множество разных нотаций, конфликтующих и не формализованных. А времена, когда можно было "минобороны велело COBOL" - прошли.

Одно другому не противоречит. Можно быстро компилировать у разработчиков и медленно оптимизировать релизный билд.

поэтому и существуют дебаг и релиз сборки

ну и еще потому что в дебаг можно больше отладочной информации засунуть

Вот это "в мире -- множество..." — постановка задачи, указание ее важности. Если уж автор некоторой статьи предлагает набор правил абстрактного синтаксиса или, например, правил вывода типов, то было бы желательно избавиться здесь от любых возможных неформальных моментов. В последнее время хорошим тоном считается приводить ссылки на рабочий код в статье, чтобы читатель мог проверить результаты самостоятельно. Возможно, неплохо было бы и проверять мат. синтаксис с помощью исполнимой нотации :)

к сожалению дебаг не означает что не надо аст в SSA llvm ir разбирать :)

Точно. Для многих современных языков это отказ от завершающей трансляции в JVM или LLVM :)

не уловил причем тут жвм

вроде как там нет проблем со скоростью компиляции :)

ну вернее я помню у котлина были (хз как ща) но это были его личные проблемы

В принципе, у всех JVM-языков проблемы со скоростью трансляции. После компиляции в JVM нужно учитывать еще и время "разогрева" самой JVM. В одном проекте у нас был Web GUI на ClojureScript. Вот там было совсем смешно: трансляция в JVM, а оттуда — в JS. Простые программы транслировались десятки секунд. Я смотрел и недоумевал, как можно разрабатывать Web GUI в таком режиме :)

> В принципе, у всех JVM-языков проблемы со скоростью трансляции

впервые услышал такое. Может раньше было так

с тиеред компиляции там же вообще мгновенный старт по сути

Мне кажется более вероятным другой вариант развития, когда рабочий код будет в proof assistant, а неформальная мат. нотация в "традиционных картинках-иллюстрациях".