Может быть, кто-то укажет мне на позицию авторов языка относительно

следующего вопроса.

Почему ним компилируется именно в c и cpp? У трансляции в llvm ведь есть однозначно больше преимуществ. К примеру при разработке на си всегда нужно учитывать, что где-либо может вылезти UB. Или же если хочется оптимизировать какое-либо место в программе через SIMD, то в текущих компиляторах си это сделать во много раз менее удобно, чем в llvm.

Позиция простая, компилятор С есть везде, а llvm - нет.

Но ведь nim компилируется и в objective-c 🤔

И что в этом такого? Я думаю что это один из самых неиспользуемых бэкендов генерации.

Я не утверждаю, что в этом есть что-то "такое". С одной стороны вы говорите, что си выбрали ввиду вседоступности. А с другой стороны в nim есть бэкенд, который есть далеко не везде.

Ну да, есть бэк который генерирует objc, но компилятор objectiveC есть много где. Другой вопрос, что этот бэк генерирует текст, а не llvm PR.

В LLVM IR нет UB?

Есть. И баги там есть, порой даже куда более серьезные, чем в компиляторах си. Я про возможности оптимизаций.

В конце концов, есть NLVM https://github.com/arnetheduck/nlvm

Глянул. Он перестал развиваться?

Возможность работы с С и С++ библиотеками (помимо того что уже упомянули).

В этом отношении мне импонирует язык zig. Там в целом, я считаю, весьма уникальный подход.

Уточню: лёгкой работы, не требующей сложных конструкций а-ля java JNI.

не очень понял. почему в llvm simd проще чем в си?

Это субъектив. Мне не особо нравится пользлваться <immintrin.h> или же писать нечто подобное вручную. Лично для меня, в llvm многое из подобного выражается проще. Более того, такого же мнения разработчики языка zig. Он поддерживает целочисденные типы произвольной длины (огранияения есть) и выражается это именно в llvm.

я, признаться не очень понимаю, я понимаю, что чисто теоретически, можно что-то такое подсказать в llvm, что он соптимизирует лучше, но 1) это должно быть доступно только на уровне нима 2) это нельзя перетащить в c-код, чтобы там тоже самое указать. Я не уверен что такие случае вообще бывают, я понимаю, может в каких-то более других языках, но врядли это применимо для nim/rust и подобного

Да в целом можно. Но, может быть, многое будет зависеть от атрибутов конкретного компилятора?

как писали в одном чате, надо понимать - что: 1) llvm это то, что целиком и полностью заточено под c/cxx 2) то что на неё лезут других платформы - не сильно меняет курса llvm по тому на что он заточен/оттимизирован 3) расту остаётся только пытаться можно больше походить на c/cxx при генерации ?хинтов? для llvm, потому что пункт 1, никаких своих особенных оптимизаций раст туда не приносит, ну или совсем минимум

Вот тут из пп.1 и 3 сразу понятно что генерация С-кода в ним это эпик вин. :)

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

ИМХО практически любой из известных на текущий момент языков - сборная солянка из других так или иначе.

Я немного о другом. C++ - это как минимум 3 языка, собранных в один. Язык препроцессора си, улучшенная версия си с классами, более-менне декларативный язык, который транслируется в предыдущий. Ресурс вроде cppinsights.io - тому подтверждение.

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

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

Ну, решение сделать для макросов отдельный dsl - это скорее про тараканов в головах разработчиков А без unsafe в целом никуда.

Ну, во-первых шаблоны, а не дженерики. Во-вторых про ооп я сказал, что это улучшенный си с классами. Транслируется. Те же шаблоны легко раскрываются до опредеденного уровня вложенности. Вы можете попросить компилятор сделать это. Те же новомодные концепты часто можно представить в виде сахара над std::enable_if. Те же лямбды раскрываются в struct-классы с переопределенным operator()

Шаблоны это те-же генерики, только в профиль, отличий мизер. Улучшенный, но написаный заново, при этом реализованый так, чтобы легко интегрировать тот-же С код. Шаблоны раскрываются на уровне AST и никуда не транслируются. Концепты можно представлять как угодно, но реализованы они как, думаю что не как куча шаблонов с enable_if и уж тем-более в них не транслируются. Про лямбды не знаю, но терзают меня суровые сомнения, особенно с учётом захватов и прочего. С и С++ ABI разные в принципе и влёгкую слинковать С и С++ код не получится. То что С++ поддерживает компиляцию С кода не означает при этом что С++ куда-то там внутри транслируется в С.

Не согласшусь, шаблоны более гибки Нет, скорее си может быть внутренним языком для си++. В последнем и типизация построже будет, да и не весь код на си полностью совместим с си++. Я и не говорил, что транслируется в си. В си-подобный язык да. Любая лямбда будет транслирована в класс. Выше скинул сайт, prove it yourself. >влегкую не получится Очень часто бывает достаточно #ifdef __cplusplus extern "C" { #endif

Дженерики это название шаблонов в Жабе. Отличия минимальны. С не является внутренним языком для С++. Там вообще нет никакого "внутреннего" языка. С++ никуда не транслируется, кроме как в AST и далее в IR компилятора. Я по кишкам полазил что LLVM, что GCC, что других компиляторов. Слинковать С и С++ код нельзя просто добавив явное использование ABI C. Точнее так: чисо функции - можно, всё что касается чего-либо более сложного - можно сразу забыть.