фраза была на уровне шутки) хотя у нас есть проект, где питон запускает плюсовые треды и ждет колбеки)

Точно не поймет, кстати?

А можно несколько примеров, что вызвало такую лютую оторопь?

Не важно, что там внутри компилятора. Я именно с точки зрения программиста говорю.

дело вообще не в комплияторе

Да я выше уже написал, магия. Опции добавляются не там, где ожидаешь, например.
Я помню, как убили часа три на то, чтобы передать настройку веб-серверу что-ли, выяснилось что надо а-ля JSON отдать куда-то в настройки самого приложения.

И в то время VS категорически не умел single executable делать - он его собирал, но нежизнеспособный.

Раз в месяц какие-то несовместимости вылезали. У программистов разные версии VS и они не могут собрать executable работающий с одинаковой версией .net.
И т.д и т.п.

Все что я видел - это были явные интринсики или руками написанные блоки ассемблера.

inline asm решает этот вопрос.

Т.е. берём кусок asm из openssl или генерируем его силами clang/rustc/numba/julia и вставляем в hot path.

Цена вопроса - noninlined function call

Тогда пример, pls.
По все, что я видел в go выглядит вполне логично. Ну кроме простейших "косячков" типа необходимости make для map и ее отсутствия для slice.

Есть быстрый и без аллокаций способ превратить go-шный string (в UTF8) в C++-ный std::wstring (в UTF16), а потом также быстро это забрать обратно?
Хочу!

горутины, переключине контекста и вот это всё такое болото, но узнаете вы это когда(если) появятся рпс'ы и про то как память оно не жрет вы тоже узнаете видимо потом, как и про особенности работы gc :) ну и вообще это же консалтинг уже так что не предметно
https://blog.twitch.tv/ru-ru/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/
ну и ключевые слова для гугла Goroutines and Parallelism, Concurrency, gomaxprocs и вот это всё. Хотя если у вас 50 рпс то можно хоть на пхп писать

Строка в go - это структура из 2 полей: указатель и длина.

Я знаю как оно устроено, но это мало что дает в плане ее превращения в std::string без копирования и аллокаций, в том числе и потому, что std::string изменяемая, в отличии от гошной.

Охотно верю, но мы пока не сталкивались.

Магия .net другая, она возникает уже на этапе разработки - неинтуитивные решения, непонятный (требующий в разы больше времени на "раскопки") pipeline настроек объектов.
Оно возникает уже сразу, а не на 100 rps.

Так вся конверсия на стороне c++

Это ж фактически char* + len

А интерпретация памяти - это уже вызываемой стороне.

Вернемся чуть назад. Я утверждал вот что: если код на стороне С++ короткий/быстрый, то даже если он вдвое быстрее того, что можно написать на go, выигрыша это может и не дать из-за затрат времени на передачу параметров.

"char*" для плюсов это кодировка ANSI, а у go там UTF8 => будет неприятная конверсия в wchar_t* с аллокацией.
Ну и потом это все надо обратно вернуть. Да так, чтобы GC не сорвало крышу.

Ну что поделать если c++ не может взять буфер и интерпретировать его как utf8 строку без аллокации.

https://habr.com/ru/post/573352/

Эх, вот мы и докатились, когда в контроллер резервного питания ставят cortex M4F о 168МГц. Даже не особо удивительно, что у всех поставки сыплются

С++ возник лет за 10 до появления UTF8, так что не удивительно 😊
Наверняка есть внешние средства для строк в UTF8 , но их мутабильность в любом случае делает интероп сложной затеей. Объекты разные по сути.

звучит так что у вас никто не умел его готовить, да это не 1 exe, но собирать проекты студия могла еще с compact framework и они работали, с зависимостями и тем что должно быть установлено в core уже во много раз лучше

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