Нужны ли компиляторам универсальные парсеры?

C++ принципиально не парсится синтаксически без семантического анализа

Строго говоря, даже C. Но там можно подпереть костылями и натянуть CFG-парсер.

Шаблоны С++ позволяют определять любые рекурсивные функции времени компиляции.

не совсем любые, есть всё-таки ограничения. шаблоны – это template или constexpr? в любом случае, без информации о типах и метаданных модулей, продвинутой рефлексии в С++ это практически бесполезно. например, в отличие от того же D где CTFE функции действительно любые – доступно почти всё подмножество языка, например string mixin.

например, реализация компилятора лиспа в си: IntelLib А. Столярова на шаблонах, макросах и какой-то магии, или одного его ученика (Legioner?) Scheme4d на D v1. во-первых, исходники второго проще и прозрачнее. во-вторых, в первом есть чудесный костыль типа «операция пробел» (см. диссер) и «операция запятая», ну и по сути реализованы через объекты в рантайме, а не полностью в компайл тайме (как во второй более перспективной, но бесконечно более сырой реализации на D v1; сейчас конечно это стоило бы на современный D v2, Pegged, std.algorithm и прочие библиотеки с макросами времени компиляции переписать.

алсо, библиотеки с макросами времени компиляции на С++ типа Boost или Sphinx. там запутаться можно в лапше из template. и какие-то вещи принципиально не возможно сделать на таких макросах (например, нормальную диагностику ошибок и восстановление после сбоев парсера) что довольно легко делается в D на CTFE макросах.

тебе одной. например, [inline]foo();[/inline] это что? вызов функции, конструктора, декларация в хедере или вызов реализации функции, или перекрытая операция () и функтор? и таких приколов там много

Да есть валом языков, которые лучше крестов, при этом про потенциальной эффективности скомпилируемого кода ничем не уступают этим крестам.

Можно список?

D, rust, ATS, Go, Nim, Crystal, Pascal. Из них паскаль - самый старый и самый подающий надежный конкурент, который загнулся в результате политики закрытости от борланда. В противовес Си, который распространился, как зараза, из-за политики открытости юникса/бсд.

Требование «такой же быстрый как С» и «полностью совместимый с легаси С» было выдвинуто заказчиком, который не хотел переписывать уже оплаченные системы на С.

Ну да, проблема была на миллиард, а теперь весь мир сливает сотни миллиардов на решение проблем с компромиссным вариантом.

foo()

Как раз неудачный пример. Это точно не декларация. А остальные варианты - синтаксически одно и то же, оператор ().

Как раз неудачный пример. Это точно не декларация.

В С это может быть прототип функции.

В ansi C может, да. Но это все равно не приведет к неоднозначности парсинга, емнип.

было выдвинуто заказчиком

Никто ничего не выдвигал, потому что заказчика не было. Страуструп работал над распределённым unix-ядром и поскольку у него был опыт с ООП он решил запилить вспомогательный инструмент, как уже делал для своей докторской. Си был выбран из-за доступности на разных машинах (что было важно для исследований распределённых систем) и своих свежих (на тот момент) идей минимализма.

Подробнее можно почитать в статье «A History of C++: 1979−1991»

Ада же :) есть доступная реализация на основе GCC, GNAT. библиотеки и возможности практически сопоставимые с С++. при этом модульный с раздельной компиляцией, простой понятный человекочитаемый синтаксис, есть встроенные в язык task которые могут с разными рантаймами переводиться как в pthreads на всех платформах так и в сопрограммы. и рантайм на другом железе перенастроить просто. контракты или прочая верификация тоже есть, ну и ASIS — парсить конструкции языка и проверять на свои ошибки типа статическим анализом. только тут это интерфейс к AST и семантическому анализу встроенный, стандартная библиотека. и код на аде самой адой анализировать проще простого. правда, кодогенерировать в аду или транспилировать в неё/из неё все ещё нужно потрудиться, а то бы совсем мегафишка была (есть пара компиляторов для ценителей типа транслятора из ады в си, но там собрать их отдельная заморочка). опять же, gcc -x ada helloworld.adb -o helloworld.o генерирует почти такой же код, что и написали бы руками либо на сишечке. программа на си, которая вызывает аду отличается только рантаймом adainit();/adafinal();, то есть можно во-первых собрать со своими заглушками вместо полноценного рантайма, во-вторых, с более полноценной реализацией своего рантайма на той же аде (стандартный ключ компилятора --with-RTS=... ).

опять же, есть примеры многоязычного кода на Ада/C++ с pragma import("Cpp",...) — особенности реализации GNAT, но вроде работает (в отличие от стандартной pragma import("C",..."), которая работает везде.

в общем, можно собрать свой gcc с D/go/Ada/C++/ObjC и прозрачной интероперабельностью между всеми этими языками. кодогенератор и оптимизатор везде используется общий, gcc-шный.

ну конструкторы на декларацию похожи, например. или определение переменной или вызов метода или конструктора.

руками пишут, я так понял, в основном для нормальной диагностики ошибок и восстановления после сбоев/ошибок парсера. а вообще в том же ANTLR есть семантические (и синтаксические) предикаты для этого.

Не настолько похожи, чтобы не разобрать синтаксически. Либо я тебя не распарсил %)

Классические примеры неоднозначности:

a * b;
c (d);
e f(g);

Третий для C++, первые два - и для C тоже.

libclang, практически без вариантов.

когда то был вариант gccxml, но это не вариант – завязано на конкретную реализацию gcc, собирать его сейчас геморно, и вообще велосипед.

так что да, clang или через libclang или отдельный проход компилятора своим плагином – технологичный вариант.

ну или для любителей велосипедов, поковырять более простые чем gcc/clang компиляторы: tcc, pcc, melcc+mel (mel=лисп, melcc реализация компилятора С на этом лиспе, достаточный чтобы собрать guile и прочее, см. список рассылки Guix про bootstrapping guix на этом всём). lcc вроде бы ещё неплохо документирован, какая-то книжка по нему была.

и смотреть как там AST реализован, и в исходниках компилятора колупаться.

да, я про третий (и частично про второй)

алсо, можно foo(a,b,c); намутить с «операцией запятая» :)

В llvm нет никаких утилит для создания парсеров и лексеров

есть пример языка kaleidoscope типа питона с кодогенерацией в llvm на питоне, окамле и С++ прямо в поставке llvm. (хотя насчёт парсера там по-моему, свой велосипед).

D
Go
Nim
Crystal
эффективности скомпилируемого кода ничем не уступают этим крестам

rust
Pascal
которые лучше крестов

Найс тралленг.

Из них паскаль - самый старый и самый подающий надежный конкурент, который загнулся в результате политики закрытости от борланда.

Lazarus ему сил не предал?

Ада же :) есть доступная реализация на основе GCC, GNAT. библиотеки и возможности практически сопоставимые с С++

Ненавижу Аду. Как и C++ (не путать стандарт с оригинальной импровизацией Страуструпа), Ада вошла в мир, где доминируют старые пердуны и кабинетные протиральщики штанов. Вошла насильно, потому что старые инструменты уже не подходили, а новых никто не мог придумать. Ада плоха, но представь, что это был лучший вариант из четырех претендентов - насколько же плохими были высеры остальных. Избранные цитаты Дейкстры о каких-то из этих четырех языков: «unsalvageable mess», «these documents are a inextricable mixture of technical documentation and salestalk», «if we see a crazy argument, are we then allowed to conclude that the authors are idiots?», «technical incompetence, probably enhanced by dishonesty».

Практически всех тех продажных ярлыков, которые вешаются на Аду, в ней на самом деле нет. Есть только одно качество этого языка: он выносит мозг писателю до тех пор, пока тот сам не начнет досконально понимать написанную им программу.

Да, можно рассматривать Аду как конкурент С++ - только потому, что два примера плохих языка, и из них можно выбирать более плохой и менее плохой.

Да, с перегрузкой запятой Бьярн тоже знатно прикололся…

парсер на регулярках

тогда уж взять какой-то compiler compiler который напрямую EBNF поддерживает: Coco/R, или на окамле что-то такое было неоднократно (алсо парсер ABNF из Stratego/XT проекта («из коробки» всё есть в одной IDE на основе Eclipse: Spoofax) к этому близок)

преимущество что можно просто копипастить из спецификации.

Найс тралленг

Тебе ответить есть что? Если нет, то давай досвидания.

Из них паскаль - самый старый и самый подающий надежный конкурент, который загнулся в результате политики закрытости от борланда.

Lazarus ему сил не предал?

Ты в курсе, когда были созданы FPC и лазарус? Где-то в конце девяностых. Это при том, что объектный паскаль уже в 1986 был, одновременно с C++. Эти 10 лет опоздания и стали фатальными.

Тебе ответить есть что?

Ну собсна ты и отвечай как язычки с GC, медленным ffi (c) могут быть эффективнее плюсов.

Ада плоха

чем? по примерам и простым поделкам, по ощущениям — простой практичный язык

но представь, что это был лучший вариант из четырех претендентов - насколько же плохими были высеры остальных

типичный «тендер под конкретного заказчика», кстати. все предложенные языки были с паскалеподобным синтаксисом.

Избранные цитаты Дейкстры о каких-то из этих четырех языков:

которые он писал ещё до стандартизации Ада83, в 78 году??? про недоделанный прототип?

те же Ada95,2005,2012 по ощущениям — простой практичный паскаль с асинхронщиной и параллельными процессами из коробки.

Практически всех тех продажных ярлыков, которые вешаются на Аду, в ней на самом деле нет.

каких ярлыков и кто и кому продаёт эту лапшу на уши? и зачем?

Есть только одно качество этого языка: он выносит мозг писателю до тех пор, пока тот сам не начнет досконально понимать написанную им программу.

и что в этом плохого? чем это лучше типичного упоротого кода на С++ с шаблонами шаблонов поверх шаблонов типа буста или Sphinx?

по крайней мере, этот псевдокод легко читается. и чукча писатель может сам станет не <косноязычным<шаблоно<писателем>>

Да, можно рассматривать Аду как конкурент С++ - только потому, что два примера плохих языка, и из них можно выбирать более плохой и менее плохой.

при этом один из них ясен, понятен и разумно структурирован — а во втором эта сложность вывалена вся сразу, прямо на неокрепший моск чукчи-писателя.

а какой тогда хороший, по твоему? и в чём он хорош?

есть два типа языков – красивые, академически правильные и которые реально используются

сказал в качестве отмазки Бьярне Страуструп, ниасилив нормальное, правильное и красивое проектирование своей сложности.

предлагаешь писать компилятор на XSLT? :))

Бьярн немного прям ошибок сделал. Во-первых, многое еще никто не знал как сделать правильно. Во-вторых, всё нужно было натянуть на C, и это редко можно было сделать красиво/«правильно».

Ну собсна ты и отвечай как язычки с GC, медленным ffi (c) могут быть эффективнее плюсов.

И у крестов есть FFI к Си, и что с этого? Из перечисленных языков не может работать без сборщика разве что Go - для D есть стандартные либы с явным высвобождением памяти.

И у крестов есть FFI к Си, и что с этого?

У плюсов он быстрый, без оверхедов.

Из перечисленных языков не может работать без сборщика разве что Go

Crystal же еще. Ну давай, рассказывай как c GC, убогим компилером и медленным ffi он будет обгонять плюсы.

Бьярн немного прям ошибок сделал. Во-первых, многое еще никто не знал как сделать правильно. Во-вторых, всё нужно было натянуть на C, и это редко можно было сделать красиво/«правильно».

Да невозможно на C натянуть новый язык красиво/правильно - сама эта постановка задачи гарантировала провал, который и произошел. Си - далеко не самый лучший и грамотно спроектированный язык. В итоге все равно вызовы функций на Си в крестах оформляются через extern C, есть кучу мелких несовместимостей.

Всё так, кроме того что произошел провал. Есть сильное подозрение, что он был бы без совместимости с C. Точнее, был бы еще один красивый язык в истории. А так - один из столпов индустрии в прошлом и отчасти сейчас (безотносительно того, насколько он хорош).

Собсно, про то и цитата автора. У него был выбор, и он выбрал практичность.

Во-вторых, всё нужно было натянуть на C

но зачем? зачем, что Obj C что C++ пытаются расширить С смоллтоковым или Simula67 синтаксисом, зачем эти 2 языка в одном (а затем 3 языка в С++: си, си с классами, шаблонная магия, или даже больше, блямбды и прочие концепты)

это ведь путь в никуда? прямое противоречие юниксвейности — делать одно дело, и делать его хорошо ?

Язык низкоуровневый, когда используемые им концепции отображают несущественное

вот царь упивается тем, что блямбда в цепепе семантически нагружена, а по-моему это просто каша из ASCII-символов, а не исходник. зачем это всё писать в одну кучу, почему не отдельно, модульно?

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

чем плох например pragma import(C, C_printf,"printf") в Ада или нормальный FFI в лиспе вместо С++-подобных костылей и расширения сишечки?

хотите сишные библиотеки — ну и пишите их на сишечке. отдельном языке. зачем нужно не FFI встраивать в язык а язык сишечки в язык расширенный? тем более они всё равно разные — например ссылок & в С++ нет в Си, отображение не прямое.

зачем нужно ABI делать разное компилятороспецифичное? почему не стандартизировать его как в том же многоязычном компиляторе?

в общем, много вопросов. и основной: сколько можно педалировать ассемблер (сишечку) в язык высокого уровня?

У плюсов он быстрый, без оверхедов.

И с какого перепуга другой статически компилируемый язык будет int и ссылку на массив байтов передавать медленнее?

Crystal же еще. Ну давай, рассказывай как с медленным ffi, убогим компилером и медленным ffi он будет обгонять плюсы.

У кристала нет стандартной библиотеки с ручным высвобождением ресурсов. У D есть, например. В остальном кристал не ограничен принципиально сборщиком, и если завтра какая-то очередная AT&T впряжется под кристал, то всё это будет - просто это никому не нужно.

В итоге все равно вызовы функций на Си в крестах оформляются через extern C,

наоборот: вызов С++ функций в Си возможен только через отключение манглинга имён (для чего extern C) и сишные обёртки к с++ коду (который напрямую экспортировать обычно невозможно, ибо ABI C++ не стандартизирован by design. но можно извратиться: см. qte http://qte.ucoz.ru/ , биндинги к D и форту ( http://mdw.narod.ru ), например. там взяли форт, подгрузили Qt, вызвали ручками конструктор/методы невиртуальные/методы виртуальные/деструктор, и вперёд. правда, происходит стирание типов и тех же шаблонов, макросов и проч. таким образом не достучаться. но в целом вызывать руками можно – вот пример. если знать как ABI устроено. )

в общем, в кривой интероперабельности с С++ виноват исключительно сам цепепе.

другой более прямой пример – многоязычный компилятор и многоязычные программы, с несколькими рантаймами. например, те же gcc + gdc + objc компилятор + gnat. опять же, если считать что основные отличия в рантайме, что нам мешает руками собрать некоторый stub типа _tmain в WinAPI, который запускает запускалку нужную, предварительно обернув runtime_init()/runtime_final() этот наш real_main? или несколько, real_C_main, real_D_main, real_Ada_Main и прочее?

всё равно же код который генерируется в *.o всеми этими компиляторами – практически тот же самый, используя общий кодогенератор и бекенд компилятора?

биндинги к D и форту ( http://mdw.narod.ru

здесь: http://mgw.narod.ru/doc.htm , а то там какая-то блямбда на глагне

И с какого перепуга другой статически компилируемый язык будет int и ссылку на массив байтов передавать медленнее?

google -> go slow ffi

В остальном кристал не ограничен принципиально сборщиком

Ну в общем то и плюсы не ограничены никак. В компилятор добавляешь -c++-v2, и там крутой язычек, все само пишется. От.

ты не гугли, ты мне пальцем покажи. вот есть Язык1 и есть Язык2, и типы Языка1 отображаются на типы Языка2. если отображение прямое, 1:1 то почему Язык2 должен быть медленнее Языка1?

зачем тут вообще какие-то накладные расходы на FFI, ну где же хвалёный зерокост? допустим, вся эта трансляция выполняется во время компиляции, CTFE. и в рантайме никакой трансляции нетути.

ладно там лисп с тегированным данными, тайптегами. так там тоже наиболее ходовой FIXNUM стараются делать с тайптегом 0 чтобы типичные операции типа +,-,*,/ выполнялись без накладных расходов. накладные расходы будут только в рантайме кода складываем яблоки с апельсинами (и assert вокруг чтобы этого не было). но при нормальных декларациях типов никаких assёртов не нужно.

а нормальные языки-то тут при чём? почему FFI именно slow, если типы и там, и там – одинаковые, одни и те же?

Не забивай лишним голову, через год другой metaprog выйдет, не прототип, там будет учтен опыт предыдущих поколений.

но зачем?

Очевидно, Бьярн хотел (и получил) пользователей своему языку. А пользователи не хотят переписывать свой код.

Вряд ли дело было в библиотеках. Хотя всё равно extern удобнее чем FFI.

зачем нужно ABI делать разное компилятороспецифичное? почему не стандартизировать его

Стандартизовали в какой-то мере.

сколько можно педалировать ассемблер (сишечку) в язык высокого уровня?

Ну, C с появления в нем абстрактной машины уже формально высокоуровневый. А дальше просто регулируем высоту. А чо, прикольно же :D

Всё так, кроме того что произошел провал. Есть сильное подозрение, что он был бы без совместимости с C. Точнее, был бы еще один красивый язык в истории. А так - один из столпов индустрии в прошлом и отчасти сейчас (безотносительно того, насколько он хорош).

AT&T в то время схавало бы любой кусок дерьма - лишь бы он вонял меньше, чем Си. Я меряю язык по его фактическому качеству, а не по коммерческому успеху - этот коммерческий успех дал нам огромную гору текущего, падающего, и уязвимого к удаленному выполению софта. Кресты просто дают возможность написать в десять раз больше строк перед тем, как всё те же проблемы Си начнут убивать софтину. C++, при всей его монструозности, дал ровно две полезные вещи:
- контролируемое высвобождение данных (но само определение точки высвобождения сделано отвратительно);
- использование обобщенных структур кодом. В си обычно либо обобщенные макросы используют код, либо обобщенные макросы пропускают через себя тип без изменения. Но макросы не могут стирать тип, абстрагируя его для использующего кода, не могут подстраивать свой тип под использующий код, что ограничивает возможности наращивания абстракций.

Собсно, про то и цитата автора. У него был выбор, и он выбрал практичность.

Он выбрал хороший маркетинговый ход. Это не практичность - это продажа. Потому что заказчик обычно - дебил. Страуструп до сих пор обтекает и притворяется, говорит аккуратно и не говорит лишнего - он очень хорош в этом, он вполне сознательно работает идолом.

tl;dr: автопрограммист автор

//гуглкапча предлагает велосипеды. откуда он знает?

go slow ffi

У го медленный FFI - дальше что? Тебе рассказать, сколько чисто сишных интерфейсов оказалось медленными?
https://blog.filippo.io/rustgo/

В остальном кристал не ограничен принципиально сборщиком

Ну в общем то и плюсы не ограничены никак. В компилятор добавляешь -c++-v2, и там крутой язычек, все само пишется. От.

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

через год другой metaprog выйдет, не прототип

прикрути автопрограммиста к постскрипту с векторными проводочками, и рисуй метапрога копипастя в ghostscript консольный

С таким же успехом можно сравнивать cfront 1982 года с современными крестами.

c современным vala, лол. примерно такое же сырое нечто.

и принцип похожий: кодогенерировать в сишечку из высокоуровневого объектно-ориентированного. когда-то был там профиль POSIX – настраиваемый рантайм без Glib/GObject (там и до сих пор можно объекты делать не наследуемые от GObject, с ручным управлением памятью и т.п.). то есть такой недо vala c минимальными зависимостями (и примерно как в D где половина конструкций языка не работала из-за завязки на конкретный рантайм).

ну потом наверное кто-то прикрутит когда-нибудь COM, .NET рантайм вместо GObject и получит какой-нибудь очередной MS Java из всего этого.

Ну, допустим, язык получился плохим (спорно). Допустим, проблем в сумме стало не меньше чем в C (тоже спорно). Всё равно непонятно, в чем претензия? Нужно было просто ничего не делать? Лучше бы весь этот падающий/уязвимый софт оставался на C?

Сделать еще один несовместимый язык - это и есть примерно «ничего». Такого было сделано навалом, а толку.

Это не практичность - это продажа. Потому что заказчик обычно - дебил

Да кто заказчик-то? И где деньги? :D

Вы с той «девочкой», похоже, что-то знаете.

Я тебе пишу о том, что в компиляторы и стандартные библиотеки крестов ввалены десятки миллиардов долларов.

В какие из? В отличие от «типа простых языков» у С или С++ сотни различных компиляторов.

С один из тех языков который есть везде, потому что он простой и для разнообразных систем и архитектур его могут написать одиночки. А какой-нибудь Go/Rust/D не могут написать одиночки, поэтому их и нет например на Эльбрусе, и когда прекращается поддержка какой-нибудь ОСи, то все программисты просто сосут, как было с Go и минимальной требованию к ОС OS X 10.11…

Примеры компиляторов написанных одиночками:

https://github.com/LADSoft/OrangeC

https://www.pellesc.de/index.php?page=start&lang=en

В императивном стиле композиция несколько болезненна.

Изучение комбинаторных парсеров с Rust

Примеры компиляторов написанных одиночками:

Guix Reduces Bootstrap Seed by 50% :

Work started three years ago with a simple LISP-1.5 interpreter.

A year later, Mes 0.5 had become a tiny Scheme interpreter written in simple subset of C that came with a simple C compiler in Scheme. And yes, these were mutual self-hosting.

The next step was to find a path towards compiling Guix’s default GCC (5.5.0). Sadly, bootstrapping GCC compilers has been becoming increasingly difficult over the years. We looked at GCC 1.42: not easy to bootstrap (100,000 LOC) and it depends on Bison. Reluctantly, we started looking for non-GNU alternatives 8cc, pcc, cc500 but finally settled on TinyCC. TinyCC (TCC) can compile GCC (4.7.4) which is currently the most recent release of GCC that can be built without a C++ compiler.

Another year later, Mes 0.13 has grown its own tiny C library and compiles a heavily patched and simplified TCC. This looked very promising and we suggested for TinyCC to help our bootstrapping effort by moving towards a simplified C subset. Instead we were encouraged to make MesCC a full blown C99 compliant compiler. That felt as a setback but it gave us the perspective of removing TCC from the bootstrap later on. Using Nyacc, the amazing parser framework with C99 parser by Matt Wette, has even made that a feasible perspective.

It took only half a year to mature into Mes 0.19 so that building TinyCC (25,000 LOC) now only takes ~8min instead of the initial 5h.

With a bootstrapped TCC we tried building some versions of GCC (1.4, 2.6.3, 2.95.3, 3.0, 3.1, 3.2.3, 3.4.0, 3.4.6, 4.1.1, 4.1.2) to try to build some versions of glibc (1.06.4, 1.09.1, 2.0.1. 2.1.3, 2.3, 2.3.6, 2.2.5, 2.12.2, 2.15, 2.16.0, 2.28) using slightly less versions of Binutils (1.9, 2.5.1, 2.5.2, 2.6, 2.7, 2.10.1, 2.14, 2.14a, 2.15a, 2.17a, 2.18a, 2.20.1a, 2.23.2, 2.25, 2.28). There were many interesting dependencies, tradeoffs, patching of generated Autotools outputs, especially if you are using your own tiny C library and headers.

Mes 0.5 released:

* About

Mes aims to create full source bootstrapping for GuixSD: an entirely source-based bootstrap path. The target is to [have GuixSD] boostrap from a minimal, easily inspectable binary --that should be readable as source-- into something close to R6RS Scheme.

It currently consists of a mutual self-hosting [close to Guile-] Scheme interpreter prototype in C and a Nyacc-based C compiler in [Guile] Scheme.

Mes mes-m2 M2-planet mescc-tools:

M2-Planet

The PLAtform NEutral Transpiler, when combined with mescc-tools; allows one to compile a subset of the C language into working binaries with introspective steps inbetween.

A lovely set of examples of M2-Planet programs are in tests but the most surprising part of all M2-Planet can self-host M2-Planet.

Лучше бы весь этот падающий/уязвимый софт оставался на C?

С момента создания Cfront (1983) прошло уже более 35 лет, а софт на C++ все еще падающий и уязвимый. Проблемы с безопасностью языка Си в C++ окончательно решены не были.

В какие из? В отличие от «типа простых языков» у С или С++ сотни различных компиляторов.

И сколько этих компиляторов C++ поддерживают последний актуальный стандарт C++?

У го медленный FFI - дальше что?

Понятно.