Во время доклада на Дне Оберона были ремарки по поводу "огромного" размера пустой программы на Go. Также автор упоминал негативные ("прожорливые", хотя на фоне тех же Java c Net-ом ...) результаты от "компонентных" экспериментов на Delphi в 2000-х гг., предшествующих проекту ВИР.
В самом деле, в те времена для Delphi возникла библиотека KOL (Key Objects Library), которая продемонстрировала "аппетиты" типового ООП-подхода, показав на порядок меньше (плюс эффективнее использование памяти, да и скорость...). Стандартная VCL в Delphi имеет традиционный раздутый абстрактный и виртуальный слой. Компилятор и линковщик из-за механизмов наследования и, прежде всего, таблиц виртуальных методов не могут "выкидывать" неиспользуемую "виртуальщину". В KOL использовали старый борландовский тип "object" вместо "class" и "interface", имеющий компактнее формат (в сравнении с "interface" -- и меньшую стоимость виртуального вызова), был задействован крайне минималистический набор виртуальных методов. Чтобы не разбухало RTTI вынуждены были не плодить типы для реализации визуальных "control"-ов, был общий TControl с огромным набором методов для всех случаев -- последствия обхода особенностей системы сборки (или всей системы). Также оказалось, что на размер конечного образа влияет большое количество исходных файлов-модулей, в результате применялись огромные модули (но в малом количестве) с массой содержимого. Предусматривалась замена стандартных системных модулей (которые могут через секции инициализации/финализации задействовать много чего нужного, однако не во всех программах) и др. Была возможность не использовать механизм исключений или задействовать в ограниченной форме на основе объекта исключения единственного класса. Архитектура объектов предусматривала адекватное внедрение зависимостей. Например, некая "техническая" процедура обработки событий от ОС определенных типов попадает в конечный образ только в случаях, если для объекта будет задан соответствующий "пользовательский" обработчик события (зависимость явного использования "технической" процедуры задаётся лишь в единственном месте -- в процедуре установки обработчика события). И пр.
Ранее в теме была ссылка на
JSC -- альтернативное новое поколение компонентной модели. Также информация без полного охвата, вроде бы, речь больше о программировании "в большом" (грубо, "фабрики типов"), не ясно насчёт программирования "в малом". Однако, докладчик говорит о переписывании или реализации системы "на Си с классами" (своё "наколенное" ООП), утверждает, что производительность и пр. существенно лучше, чем решение на основе Qt.
Имхо, "компонентный ассемблер" для программирования "в большом" ("сборочного") вряд ли будет приемлемым без адекватного "ассемблера" и для "синтезирующего" программирования.