2. Си — это переносимый ассемблер.

Мне.
Такой компилятор позволит вести вполне промышленную разработку с меньшей головной болью, чем это происходит сейчас у меня лично и у всех тех бедолаг, которые пользуются JavaScript, python, и т. п.
golang тоже местами вовсе не блещет (разбор от коллег по цеху есть на хабре, а также в чате Телеграм-канала, где Олег был модератором (тролли набежали, канал испортили).

"Промышленный" -- означает "предоставляющий гарантии правильности трансляции семантики на уровень машины".
Пусть он не будет супер-скоростной, но пусть он будет предсказуем.
Либы, кросс-компиляция, средства сильной статической и (в меньшей степени) динамической проверки приветствуются.

Кто-то запустил эту манипуляцию в массы, и теперь все повторяют. Но
1. Си - это не ассемблер.
2. Любой язык ассемблера переносимый.
3. Транслировать можно в любой алгоритмически полный язык

4. И не очень-то он (без #) переносимый.

2. Любой язык ассемблера переносимый.

После прослушивания возник вопрос Олегу: о каких размерах выигрыша (в скорости, в размере кода) может идти речь если компилировать не сразу в машинный код, а через компиляцию в Си?

Также прошу Константина прояснить фразу:
(а то странно, я вот до сих пор думал, что язык ассемблера это самый НЕпереносимый машинный язык)

Вот код для 64-разрядной архитектуры MIPS, вот – для 64-разрядной архитектуры POWER. Вы можете заметить, что они похожи. Причина в том, что они, по сути, являются одним и тем же языком. Отчасти потому, что они так устроены: по сути дела, мы 30 лет использовали ассемблер National 32000, меняя только лишь железо, на котором он использовался. Но ещё и потому, что некоторые из них действительно идентичны. Это просто инструкции, регистры, операнды, константные значения, метки — всё одно и то же. Единственное важное отличие заключается в том, что у инструкций и регистров разные имена. Ещё иногда отличаются смещения, но это зависит от размера машинного слова.

Всё это сводится к ассемблеру National 32000, который написал Кен. Это язык ассемблера National 32000, каким его себе представляет Кен, адаптированный для современного PowerPC. Таким образом, у нас есть всё необходимое — общий язык ввода, библиотека obj в бэкэнде – и мы можем писать на ассемблере. При таком подходе возникает проблема: если взять руководство National или PowerPC и взглянуть на язык ассемблера, то окажется, что он выглядит не так. У него другой синтаксис, иногда другие имена инструкций, потому что на каком-то уровне это фактически псевдоинструкции. На самом деле, это неважно.

Непосвящённого человека внешний вид ассемблера Go — все эти заглавные буквы и странные штуки — может серьёзно смутить. Но поскольку для всех этих компьютеров у нас есть общий язык ассемблера, мы можем получить замечательный результат, о котором речь пойдёт ниже. Поэтому мы считаем, что это оправданный компромисс и достигнуть его не очень сложно. Стоит научиться программировать на 68000 и на ассемблере Кена – и вы автоматически сможете писать программы для PowerPC. Какая разница?

Без теории люди часто не видят за деревьями леса, но я не хочу вдаваться в теорию, поясняя, что означает алгоритмическая полнота. Скажу только, что в мире было сделано много самых разных средств для запуска программ, изначально написанных для других архитектур. Это и есть переносимость.

Вот код для 64-разрядной архитектуры MIPS, вот – для 64-разрядной архитектуры POWER. Вы можете заметить, что они похожи. Причина в том, что они, по сути, являются одним и тем же языком. Отчасти потому, что они так устроены: по сути дела, мы 30 лет использовали ассемблер National 32000, меняя только лишь железо, на котором он использовался. Но ещё и потому, что некоторые из них действительно идентичны. Это просто инструкции, регистры, операнды, константные значения, метки — всё одно и то же. Единственное важное отличие заключается в том, что у инструкций и регистров разные имена. Ещё иногда отличаются смещения, но это зависит от размера машинного слова.

У него другой синтаксис, иногда другие имена инструкций, потому что на каком-то уровне это фактически псевдоинструкции. На самом деле, это неважно.

Для этого нужно организоваться. Большинство нынешних разработчиков трансляторов Оберона хочет всё делать либо в одиночку, либо "объединять" сообщество вокруг своего проекта.