Эта прелесть никак не связана с темой. Она возникает потому, что в этой языке возможностей куда больше. Нет нет альтернативы, которая бы могла всё тоже, но как-то иначе. Выразительные возможности паскаль-стиля крайне скудные.
В си-стиле выражается void(a, b, c); В паскаль стиле нет. В том же TS приходится эмулировать сишный стиль через (a, b, c) => void, т.е. семантика потекла. Нужно два синтаксис для определения типа и функции.
И таких примеров масса. К тому же не стоит сравнивать скриптуху, где одни ссылочные типы и си. Это разные весовые категории. Это как сравнивать С++-лямбду и js-лямбду.
жс-лямбда мало того, что дырявая(вы не сможете там определить тип возврата), дак ещё и десятой долей функционала не обладает. Конечно, манипулировать и сравнивать несравнимое удобно. Но не стоит так делать.
На мой взгляд, такой стиль побуждает думать сначала о смысле переменной, а потом уже выбирать подходящий тип.
Тип и определяет смысл.
множество
Тут ваша логика дала течь. Множество уже тип, вы подумали о типе до.
Опять же, существует два варианта — от данных, либо от операций. От данных — это когда у вас уже есть логика, которая генерирует данные и типы их уже выбраны. Тогда вы в первую очередь должны писать тип.
От операции. Ты вы пытаетесь реализовать какую-то операцию и в процесса выводите тип. Очевидно, что этот процесс находится в теле функции и с какой он находится — неважно. Абсолютно.
Ни от какого auto паскаль-стиль не уходит, а наоборот требует ввод кейворда для обозначения декларации переменной. Таким образом вы всегда будите писать синтаксический мусор вместо типа. Всякие там var, let и прочее.
С типом будет ещё больше мусора, а именно let/var name: type, а не type name;
Аналогично можно заметить, что гадить адепты раста могут, а отвечать нет. Они приходят в тему про С++ и загаживают их своим «языком», который никому не интересен и ненужен. Так же прибегают в темы про С++ и минусуют всех, кому не интересен их объект обожания.
Ну в целом это очень хорошо. Чем больше таких набегов анонимных загаживателей будет — тем больше наблюдатель со стороны будет знать. Знать кто они и что они.
Я тут опять начал распылятся. Хотя для опровержения всех эти рассуждений достаточно вопрос — «почему в раст пастят constexpr и const generics»? Зачем это нужно, если уже язык — метаязык.
А ответ тут прост. Те, кто создают и добавляют это в раст — знают реальное положение дел. А эксперты в комментах — лишь эксперты в комментах, которые очень часто врут/выдают желаемое за действительное.
И вот такой вот у нас(них) метаязык. На словах. А в реальности — отдельный ужасный язык макросов, а так же расширения компилятора.
Не было там изначально нифига. Изначально шаблоны вообще планировались как параматризованные типы в Extended Pascal, но кому-то пришла в голову светлая мысль со специализациями шаблонов.
Как это не было, если было. Там было всё. И вы это подтвердили.
После чего оказалось, что, во-первых, эффективно реализовать шаблоны после этого затруднительно с одной стороны, а с другой — было выяснено, что они — полны по Тьюрингу (а да — известно кто и когда это сделал).
Это то, о чём я и сказал. Выяснили, что они пригодны для вычислений. Но кодогенерация и всё их устройство оных было изначально.
Ну а дальше — начали вокруг этого надстраивать многоэтажные уровни костылей.
А ну именно поэтому в расте теперь пастят constexpr и const generics. А так да, ни на чём не обоснованные громкие заявления.
Принципиально ужасней лиспа оно тем, что у вас два разных языка. А не один, как во всех системах с приличным метапрограмированием сделано.
У вас явные проблемы с восприятием. Именно в лиспе, расте и прочих сделано два отдельных языка. В С++ язык один. Так было всегда.
Но ничего и не помогает. Стандартного способа нет.
Покажите мне стандарт раста. Я посмотрю на него. А так же покажите мне там стандарт на расширения.
Это не глупо. Это как раз принципиально. Вы можете сделать не просто модуль, который может как угодно обрабатывать то, что вы пишите на своём языке — вы можете добавлять сущности описанные во внешних файлах или даже базах данных.
Это так смешно читать в контексте раста. Который существует в рамках llvm-экосистемы и является таким clang-ом на минималках.
Когда это появился в C++? В C++40? Или в C++80?
Это уже есть. А у лиспа ничего нет. И ничего не было. Это всё враньё и инсинуации, а вы ничего не покажете. А что покажете, если покажете, это детский садик в современных реалиях.
А в LISP — это всё было в 60е.
Ничего в леспе и никогда не было. Зачем вы врёте? Никакого аналога описанных в статье фичей не было и нет. А то, что там было — это уровень чуть выше препроцессора в си. Всё это не обладало и не обладает ничем, чем обладают реализации того же на С++. Это не является ни статическим, ни компилируемым, ни имеет никаких средств статического анализа уровня того же libclang/gcc. Не имеет ничего даже близко равного libclang.
В rust — это можно сделать сегодня (хотя diesel появился чуть раньше и, увы, основан на кодогенерации.
Точно так же это можно сделать и clang.
Вы пропустили самый главный вопрос: а зачем нам вообще метаязык. Зачем нам все это costexpr и прочая муть? Почему мы не можем просто разрешить обычному коду на C++ работать во время компиляции?
Неверно. Во-первых constexpr это и есть возможность работать во время компиляции. И ничего этого нигде(в полной мере) нет.
К тому же, вы в очередной раз проигнорировали неудобные вопросы.
Э… вас часом с детстве не роняли? Идти туда, где проще — это как раз девиз Unix, C и C++. Про это даже статью известную написали.
Полная чушь. Юникс куда более сложный, чем всё существующие тогда/сейчас. Это авангард развития ОС и технологий. Просто — это всякий треш 90х уровня бейсика, паскаля и прочего.
Или вы исходите из того, что C++ сложен, а какой-нибудь Scheme прост — то, значит, С++ было сложно сделать, а Scheme просто?
Это очевидно.
Как бы не так: забить костылей, а потом подпереть их ещё одним рядом костылей и так — 100500 уровней костылей… это как раз просто. Сложно — сделать всё то же самое не множа сущностей без необходимости.
Именно таким образом и развивался раст. В С++ никто и никогда не добавлял никаких костылей.
С++ является самым сложным языком по части реализации. Сишный синтаксис является самым мощных и расширяемым синтаксисом. Именно поэтому у них самые мощные компиляторы, т.к. именно эти языки и позволили создать эти самые компиляторы. Аналогично и совсем остальным.
C++ захватил рынок именно потому что он был крив и ужасен.
Какая нелепая чушь. Эту глупую мантру повторяют адепты всякой маргинальщины уже десятки лет. Это было и с си. Тоже самое рассказывали адепты паскаля. Потом эти адепты меняли паскаль на новые убийцы, но умирали вместе с ними.
Звучит парадоксально — но факт.
Ну когда тебе нужно оправдать неудачи того, чьим адептом являешься — кидаться подобным очень удобно.
Потому что пока остальные всякие Haskell'и и Scheme разрабатывали грамотную архитектуру
И, где эти языки? Где их архитектура? Где софт на них? Я отвечу — лишь в фантазиях их адептов. Так было, так есть и так будет. Этой истории уже 50 лет. И пластинка не меняется.
— создатели C++-компиляторов зарабатывали деньги. Ибо у них уже был продукт, который можно было продать.
Опять же — полная чушь. Кто создавал gcc? Столман на коленке. Тот же llvm — академический проект. Но всё это было состоятельным, всё это работало. Во всё это потянулись люди и инвестиции.
К тому же, все эти компиляторы маргинальные — это попросту уровень нулевых годов. Они не являются даже конкурентами актуальных С/С++ компиляторов.
Лисп как раз не умер.
Умер. Это факт. Вы просто врёте и подменяете понятия. Лисп умер, развалившись на тонны маргинальных диалектов. Потом эти диалекты пытались собрать — родился тот же cl. Но всё это 90е годы.
Тут можно заметить типичную схему манипуляции, которую использую адепты лиспа. Они называют лисп, но в одном контексте — это убогий лисп из 60-70х, который любой студент писал на коленке. Да и так он и родился. А в другом лисп современный, т.е. всякие там cl/scheme. Причём не те старые его редакции, из 80/90, а именно актуальные.
Если адепт пытается говорить про лисп из 60х — он должен говорить именно про тот лисп.
А вполне себе активно используются. Людьми, которые понимают что делают. К сожалению таких в современной IT-индустрии немного — это да.
Никто не использует лисп из 60х. Это очередная попытка врать. Как и никто не использует си с классами из 70/80х.
По поводу того, что кто-то использует — очевидно, что маргинальщину используют. Но это никого не интересует. Все должно интересовать — где плоды этого использования? Но их не видно, на фоне всего остального — это пыль.
Если вы про десятое правило — то да, разумеется. Иначе и быть не могло.
Нет. Я про обрастание костылями и усложнение.
Желание сделать нормальное метапрограммирования привело сначала к лиспу
Нигде и никогда оно к нему не приводило.
(программирование variadic templates — это как раз типичный Lisp и есть)
Полная ахинея. variadic существовал в си и С++ для макросов/параметров функции десятки лет. variadic — это просто продолжение этой идеи.
а теперь там появляются аналоги CLOS (концепты — это как раз об этом) и прочее.
Опять же глупое враньё. Это ахинея уровня «колёса в современном автомобиле — это аналоги колёс из телеги. Было же в теле — взяли из телеге». Это манипуляции, когда манипулятор пытается сравнивать слова, но не то, что за ними стоит. Тоже самое было с лиспом.
Очевидно, что какое-то убогое говно сделать просто. Как просто выточить колесо у телеги. Но названия уже сотни лет ничего не определяют. Определяющими является свойство конкретного колеса, конкретной модели колеса.
Отнюдь. Тот факт, что каждые лет 10-15 кто-то изобретает Лисп в очередной раз
Опять же полная и нелепая чушь. Это примерно так же как говорить, что кто-то каждый раз изобретает автомобиль. Ещё раз повторю — никакой лисп ничего не может и никому и никогда интересен не был. А тот факт, что там появились и использовались какие подходы — обусловлено лишь тем, что никаких требования к лиспу не предъявляется. Именно поэтому в него можно тащить любое дерьмо.
В С++ же совершенно другие критерии, когда как в лиспе критерий один «лишь бы как-то работало». Такой же критерий существует и для раста. Один.
(вот и C++ в верссии C++11 до него добрался, а в версии C++20 у нас уже почти что CLOS, то есть не просто LISP 60х, а «продвинутый» LISP 80х)
О боже, какая же нелепая чушь. Ещё раз повторю. Само наличие какой-то кодогенерации(в ситуации с лиспом — генерации текста) и предкомпиляции(т.е. интерпретации кусков какой-то примитивной скриптухи, которой является лисп) — ничего не стоит. Такую херню писали и пишут студенты на лабах.
Особенно это было модно в 60-70. Всякие m4 и прочее сишной наследение. Да сам С++ тем же самым в начале своего становления языком.
Поэтому я ещё раз повторю. Сам факт наличия чего-то никому не интересен. С++ нигде и никогда не занимался реализаций этой примитивной херни. Он занимался КАЧЕСТВЕННОЙ реализаций этой примитивной херни и она уже не была примитивной.
— скорее говорит о том, что подход Лиспа — это и есть окончательная точка. Просто огромное количество неквалифицированных людей, занятых в индустрии, не позволяет это «колесо переизобретения Лиспа» остановить.
Нет, именно лисп и его изобретали и говорители о нём — неквалифицированные люди. Именно поэтому они и существуют так, где существуют.
Целые специальные учреждения заняты теми, кто уже всё изобрёл и знает как лучше. Там, в мягкой палате, каждый расскажет про заговор, про некомпетентность все вокруг. Как они его гениальные творения — выкидывали.
А как же все десятки и сотни языков, созданных до rust'а? И даже до LLVM? И даже до C++?
Ну дак в этом их и проблема. Они были созданы, но никогда не могли составить никакую конкуренцию. Потому что никто из них не мог написать компилятор, особенно на рождённом ими языке.
Достоинства C++ тут очень сомнительны.
Достоинства С++ тут прямые. Именно эта инфраструктура позволила очередному посредственному языку пиариться как «быстрый язык». До llvm«а — это был бы очередной пхп. Хотя он им и был.
И даже LLVM не очень-то нужен: до этого просто языки прикручивали к GCC (который был написан на C, не на C++), вот и вся разница.
Неверно. Никакие языки не прикручивали к гцц, вернее не прикручивали массово. Зачастую они просто транслировались в си.
Но именно llvm был создан как платформа для создания подобных языков. Сделать тоже самое на гцц — куда сложнее. А как я уже говорил — все эти языки(в том числе и раст) существуют лишь на эксплуатации простых решений.
И появляются они тогда — когда прогресс позволяет простым и убогим решениям — быть эффективными. Вернее минимально эффективными. И вот llvm — это то самое. До llvm»а просто решение не было эффективно. Именно поэтому никакой раст и не мог бы существовать, как он и не существовал. Вернее он существовал, но в другом виде. И довольно долго. Правда никто реализовать его не мог.
А потом пришлось срочно всё менять и делать на llvm. По-сути создавая язык заново. Хотя это не язык, а набор никак не связанных друг с другом костылей/простых решений.
«Что-то подобное» — это что? Метапрограммирование?
Фичи описанные в статье.
Lisp в 60е имел приличную поддержку — в том числе компилируемые варианты.
Покажите. К тому же компиляция компиляции рознь. Тоже самое и с метапрограммированием. Лисп и прочие подобные представители — это просто генерация уровня чуть выше текстовых шаблонов при крайне примитивных синтаксических/статических возможностях. С тех же 60/70 годах в си были макросы и это тоже формально метапрограммирование. Но уже давно никого не волнуют формальности, а волнуют нюансы.
Scheme в 70е. Dylan в 90е.
Аналогично. Я столько слышал, но ни разу не видел. Покажите мне аналог constexpr, описанной статической рефлексии, шаблоны и прочее. Что-то уровня libclang и т.д.
Потом все увлеклись «новой игрушкой» — C++. В которой тоже было обнаружено метапрограммирование.
Оно не было там обнаружено. Оно там было изначально. Обнаружено там было другое — расширенное использование и выход на компилтайм-вычисления.
Вот собственно именно потому, что оно там было обнаружено, а не дабавлено — оно и получилось таким ужасным.
И чем же оно принципиально ужасней лиспа? Вы сможете показать сравнения ужасностей?
Однако, к сожалению, до Rust'а все языки с приличным метапрограммированием имели «толстый» рантайм, так что там, где это было неприемлемо — С++ был естественным выбором.
Раст никоим образом не конкурент С++. Из метапрограммирования там только макросы с инопланетным синтаксисом, т.к. по-сути внешний язык(как и в си). По части же компилтайм-вычислений там вообще ничего нет. Начали пытаться добавлять какие-то зачатки constexpr.
Очевидно, что сделать банальную кодогенерацию на уровне чуть выше текстовой — проще. Несоизмеримо проще, чем добавить в язык мета-возможности. Но всё это просто внешние сущности со всеми вытекающими.
Rust же, разумеется, даёт 100 очков фору C++ — потому что его создатели простую вещь:
Его создатели осознали простую вещь — идти простым путём просто, а сложным сложно. И были выбраны везде и всюду простые пути. Можно сколько спорить на тему «почему был сделан такой выбор», но выбор этот сделан — это очевидно.
если у вас компилятор написан на C++/Rust — но можно позволить просто загружать модули в него… и всё!
Ничего не понял. Что мешает загружать эти модули в С++-компилятор? Ничего. Это не имеет никакого отношения к языку. Это просто попытка разыграть карту «у нас один компилятор, а у вас много», но это глупо.
Не нужно разрабатывать десятилетиями метаязык… можно просто основной язык сделать метаязыком — и вы, вдруг, получаете на порядок больше возможностей, чем в C++20.
Где в расте какие-то мета-возможности? Зачем в мета-язык тащить аналог constexpr? Зачем там макросы на внешнем языке?
У Rust'а есть свои заморочки, конечно, но вот конкретно метапрограммирование — в нём сделано правильно… так, как в 60е в LISP'е!
Да, это действительно так. В лиспе придерживались того же пути, той же практики — идти туда, где проще. К чему это привело — все знают. Лисп умер, а то что не умерло — преобразовалось в тот самый аналог С++. Но и его положение так же известно.
Всего-то полвека потребовалось, чтобы разумный подход [почти] добрался до мейнстрима… а кто-то рассказывает сказки про то, что в IT развитие быстро просиходит…
А чего вы взяли, что этот подход «разумный»? Какие этому есть основания? История лиспа? Это контр-пример.
К тому же, года к появлению раста имеют мало отношение. А что действительно имеет отношение — это С++ и развитие его инфраструктуры. И именно компилятор(llvm) и прочий рантайм позволил расту существовать. С++ подарил ту инфраструктуру — которая позволяет кому угодно(хоть студенту первого курса) сделать новый язык, который зарулит все те, которые существовали до.
Где вы увидели в java компилтайм-рефлексию? Где вы вообще видели подобное? C++ был изначально рождён на невероятно мощном/расширяемом базовом синтаксисе(java/c# и многие другие не дадут соврать) + в основу были взяты мета/кодоген-возможности. Вот их и расширяют, а C++ находится в авангарде подобного(именно статического, именно компилтайм) функционала в языках вообще.
А C++ оставить для решения задач более ему подходящих.
Именно эти задачи и подходящие. Именно эти возможности и позволяю эффективно решать те самых подходящие задачи.
в нем ищем функцию cpu_dot, которая вычисляет скалярное произведение двух векторов на языке Rust
И получаем файл, т.к. спастил я цитату не полностью:
И в качестве примера напишем небольшую программу на Rust для вычисления скалярного произведения векторов, вычисление скалярного произведения будет производиться на GPU
вычисление скалярного произведения будет производиться на GPU
Здесь уточнение, как именно будет происходить вычисление «скалярного произведения» в «программу на Rust».
А что вы пытаетесь мне подсунуть?
cpu_dot
Который вы только что придумали, но самом деле вы то имели ввиду другое, и я это знаю, и я это доказал выше.
Хорошо, про желтый заголовок я уже сказал — ответа не было. Пошло игнорирование. Теперь касательно текста:
И в качестве примера напишем небольшую программу на Rust для вычисления скалярного произведения векторов, вычисление скалярного произведения будет производиться на GPU с использованием CUDA C.
Где вы написали на rust программу для «вычисления скалярного произведения векторов»? Я отвечу — нигде. Вы написали программу вызова си-функции из rust.
Ну т.е. статья — это чисто желтуха для «похайпить» на популярном базворде. Никакой куды нет, никакого раста нет, никакого вызова кернелов нет. Статье «вызываем си-фукцию из раста» никто бы 100 плюсов не наставил бы.
Нет, это не будет вызовом кернела. Это доказано мною выше.
Если принять мою логику то gpu_dot будет кернелом а уже эту функцию я могу вызвать из раст) Так что если принять мою логику то это изменит кое что.
Это логика несостоятельна. К тому же, зачем задним числом пытаться что-то изменять? Пока у вас gpu_dot не вызвается из раста — всё эти рассуждения не имеют смысла, т.к. вы показывали не это.
Этот туториал в том числе можно использовать как инструкцию для вызова обычного си кода из раст, в комментариях это уже упоминалось, посмотрите выше. В статье рассказывается как писать и собирать Rust + С + CUDA C.
Какое отношение к вызову си кода из раст имеет куда? Никакого. Как минимум вы должны написать «вызов си кода из раста НА ПРИМЕРЕ куды», но опять же — это будет полной глупостью, т.к. куда тут вообще не при делах.
Тоже самое и со сборкой. «сборка С++ кода через cargo на примере куда», но опять же — куда тут никаким образом не относится к теме.
В статье рассказывается как писать и собирать Rust + С + CUDA C.
Опять же, неверно. В статье не рассказывается как писать на С++ + cuda, а даже если бы и рассказывалось — причём тут раст? Так и пишите «как писать на С++ + cuda».
Я вам дам правильный заголовок. «пишем на С++ + cuda c» + «вызываем написанный таким образом код из раста». То, что написано у вас — неверно.
Эту обертку поверх обертки можно убрать, не принципиально, тут уже на ваш вкус и зависит от архитектурного решения вашего приложения. В статье приведен лишь пример не более.
Это ничего не изменит.
Да, это обычный вызов сишной функции в которой мы можем писать CUDA код (а можем и не писать, можем ее вообще не вызывать), спорить не буду, можете называть этот вызов функции как вам удобно)
Ну это принципиальный момент. По-сути из статьи можно выкинуть cuda и ничего не изменится, т.к. статья чисто про вызов сишной функции из раста.
Это просто вызов си-функции. Какая она — это неважно.
что помимо самого кернела, если вы посмотрите внимательно в файл dot_gpu.cu, есть предшествующий код в виде инициализации памяти на GPU
Я знаю, строчка упомянутая мною именно оттуда.
это все уже относится к СUDA.
Это обычный сишный рантайм. К тому же это неважно, ведь даже если мы определяем по границе cuda, то границей является gpu_dot. И даже если принять вашу логику — кернелом будет gpu_dot, но вы её не вызываете — вы вызываете обёртку над gpu_dot.
Так что вызов си-функции обвязки из раста в которой находится CUDA-зависимый код в том числе вызов самого кернела и которая возвращает результат работы кернела, можно грубо назвать «вызовом кернела из раста».
Нельзя. Это вызов обёртки dot, которая вызывает обёртку, которая вызывает кернел. dot никоим образом не вызвает кернел.
Поэтому как это не называй — это обычный вызов сишной функции из раста. Этот вызов никак не связан с cuda, вообще никак.
Паскаль-стиль не может быть единобразным — он слишком слабый даже для языков уровня js.
И в чём проблема?
Расскажите мне про прикол с:
(a, b) => c — что это?
А про [a, b, c]?
К тому же, очень наивно ссылаться на проблему, которая вообще не проблема и которую уже решили. И об этом написано по ссылке.
В си-стиле выражается void(a, b, c); В паскаль стиле нет. В том же TS приходится эмулировать сишный стиль через (a, b, c) => void, т.е. семантика потекла. Нужно два синтаксис для определения типа и функции.
И таких примеров масса. К тому же не стоит сравнивать скриптуху, где одни ссылочные типы и си. Это разные весовые категории. Это как сравнивать С++-лямбду и js-лямбду.
жс-лямбда мало того, что дырявая(вы не сможете там определить тип возврата), дак ещё и десятой долей функционала не обладает. Конечно, манипулировать и сравнивать несравнимое удобно. Но не стоит так делать.
Тип и определяет смысл.
Тут ваша логика дала течь. Множество уже тип, вы подумали о типе до.
Опять же, существует два варианта — от данных, либо от операций. От данных — это когда у вас уже есть логика, которая генерирует данные и типы их уже выбраны. Тогда вы в первую очередь должны писать тип.
От операции. Ты вы пытаетесь реализовать какую-то операцию и в процесса выводите тип. Очевидно, что этот процесс находится в теле функции и с какой он находится — неважно. Абсолютно.
С типом будет ещё больше мусора, а именно let/var name: type, а не type name;
Что конкретно?
Ну в целом это очень хорошо. Чем больше таких набегов анонимных загаживателей будет — тем больше наблюдатель со стороны будет знать. Знать кто они и что они.
А ответ тут прост. Те, кто создают и добавляют это в раст — знают реальное положение дел. А эксперты в комментах — лишь эксперты в комментах, которые очень часто врут/выдают желаемое за действительное.
И вот такой вот у нас(них) метаязык. На словах. А в реальности — отдельный ужасный язык макросов, а так же расширения компилятора.
Как это не было, если было. Там было всё. И вы это подтвердили.
Это то, о чём я и сказал. Выяснили, что они пригодны для вычислений. Но кодогенерация и всё их устройство оных было изначально.
А ну именно поэтому в расте теперь пастят constexpr и const generics. А так да, ни на чём не обоснованные громкие заявления.
У вас явные проблемы с восприятием. Именно в лиспе, расте и прочих сделано два отдельных языка. В С++ язык один. Так было всегда.
Покажите мне стандарт раста. Я посмотрю на него. А так же покажите мне там стандарт на расширения.
Это так смешно читать в контексте раста. Который существует в рамках llvm-экосистемы и является таким clang-ом на минималках.
Это уже есть. А у лиспа ничего нет. И ничего не было. Это всё враньё и инсинуации, а вы ничего не покажете. А что покажете, если покажете, это детский садик в современных реалиях.
Ничего в леспе и никогда не было. Зачем вы врёте? Никакого аналога описанных в статье фичей не было и нет. А то, что там было — это уровень чуть выше препроцессора в си. Всё это не обладало и не обладает ничем, чем обладают реализации того же на С++. Это не является ни статическим, ни компилируемым, ни имеет никаких средств статического анализа уровня того же libclang/gcc. Не имеет ничего даже близко равного libclang.
Точно так же это можно сделать и clang.
Неверно. Во-первых constexpr это и есть возможность работать во время компиляции. И ничего этого нигде(в полной мере) нет.
К тому же, вы в очередной раз проигнорировали неудобные вопросы.
Полная чушь. Юникс куда более сложный, чем всё существующие тогда/сейчас. Это авангард развития ОС и технологий. Просто — это всякий треш 90х уровня бейсика, паскаля и прочего.
Это очевидно.
Именно таким образом и развивался раст. В С++ никто и никогда не добавлял никаких костылей.
С++ является самым сложным языком по части реализации. Сишный синтаксис является самым мощных и расширяемым синтаксисом. Именно поэтому у них самые мощные компиляторы, т.к. именно эти языки и позволили создать эти самые компиляторы. Аналогично и совсем остальным.
Какая нелепая чушь. Эту глупую мантру повторяют адепты всякой маргинальщины уже десятки лет. Это было и с си. Тоже самое рассказывали адепты паскаля. Потом эти адепты меняли паскаль на новые убийцы, но умирали вместе с ними.
Ну когда тебе нужно оправдать неудачи того, чьим адептом являешься — кидаться подобным очень удобно.
И, где эти языки? Где их архитектура? Где софт на них? Я отвечу — лишь в фантазиях их адептов. Так было, так есть и так будет. Этой истории уже 50 лет. И пластинка не меняется.
Опять же — полная чушь. Кто создавал gcc? Столман на коленке. Тот же llvm — академический проект. Но всё это было состоятельным, всё это работало. Во всё это потянулись люди и инвестиции.
К тому же, все эти компиляторы маргинальные — это попросту уровень нулевых годов. Они не являются даже конкурентами актуальных С/С++ компиляторов.
Умер. Это факт. Вы просто врёте и подменяете понятия. Лисп умер, развалившись на тонны маргинальных диалектов. Потом эти диалекты пытались собрать — родился тот же cl. Но всё это 90е годы.
Тут можно заметить типичную схему манипуляции, которую использую адепты лиспа. Они называют лисп, но в одном контексте — это убогий лисп из 60-70х, который любой студент писал на коленке. Да и так он и родился. А в другом лисп современный, т.е. всякие там cl/scheme. Причём не те старые его редакции, из 80/90, а именно актуальные.
Если адепт пытается говорить про лисп из 60х — он должен говорить именно про тот лисп.
Никто не использует лисп из 60х. Это очередная попытка врать. Как и никто не использует си с классами из 70/80х.
По поводу того, что кто-то использует — очевидно, что маргинальщину используют. Но это никого не интересует. Все должно интересовать — где плоды этого использования? Но их не видно, на фоне всего остального — это пыль.
Нет. Я про обрастание костылями и усложнение.
Нигде и никогда оно к нему не приводило.
Полная ахинея. variadic существовал в си и С++ для макросов/параметров функции десятки лет. variadic — это просто продолжение этой идеи.
Опять же глупое враньё. Это ахинея уровня «колёса в современном автомобиле — это аналоги колёс из телеги. Было же в теле — взяли из телеге». Это манипуляции, когда манипулятор пытается сравнивать слова, но не то, что за ними стоит. Тоже самое было с лиспом.
Очевидно, что какое-то убогое говно сделать просто. Как просто выточить колесо у телеги. Но названия уже сотни лет ничего не определяют. Определяющими является свойство конкретного колеса, конкретной модели колеса.
Опять же полная и нелепая чушь. Это примерно так же как говорить, что кто-то каждый раз изобретает автомобиль. Ещё раз повторю — никакой лисп ничего не может и никому и никогда интересен не был. А тот факт, что там появились и использовались какие подходы — обусловлено лишь тем, что никаких требования к лиспу не предъявляется. Именно поэтому в него можно тащить любое дерьмо.
В С++ же совершенно другие критерии, когда как в лиспе критерий один «лишь бы как-то работало». Такой же критерий существует и для раста. Один.
О боже, какая же нелепая чушь. Ещё раз повторю. Само наличие какой-то кодогенерации(в ситуации с лиспом — генерации текста) и предкомпиляции(т.е. интерпретации кусков какой-то примитивной скриптухи, которой является лисп) — ничего не стоит. Такую херню писали и пишут студенты на лабах.
Особенно это было модно в 60-70. Всякие m4 и прочее сишной наследение. Да сам С++ тем же самым в начале своего становления языком.
Поэтому я ещё раз повторю. Сам факт наличия чего-то никому не интересен. С++ нигде и никогда не занимался реализаций этой примитивной херни. Он занимался КАЧЕСТВЕННОЙ реализаций этой примитивной херни и она уже не была примитивной.
Нет, именно лисп и его изобретали и говорители о нём — неквалифицированные люди. Именно поэтому они и существуют так, где существуют.
Целые специальные учреждения заняты теми, кто уже всё изобрёл и знает как лучше. Там, в мягкой палате, каждый расскажет про заговор, про некомпетентность все вокруг. Как они его гениальные творения — выкидывали.
Ну дак в этом их и проблема. Они были созданы, но никогда не могли составить никакую конкуренцию. Потому что никто из них не мог написать компилятор, особенно на рождённом ими языке.
Достоинства С++ тут прямые. Именно эта инфраструктура позволила очередному посредственному языку пиариться как «быстрый язык». До llvm«а — это был бы очередной пхп. Хотя он им и был.
Неверно. Никакие языки не прикручивали к гцц, вернее не прикручивали массово. Зачастую они просто транслировались в си.
Но именно llvm был создан как платформа для создания подобных языков. Сделать тоже самое на гцц — куда сложнее. А как я уже говорил — все эти языки(в том числе и раст) существуют лишь на эксплуатации простых решений.
И появляются они тогда — когда прогресс позволяет простым и убогим решениям — быть эффективными. Вернее минимально эффективными. И вот llvm — это то самое. До llvm»а просто решение не было эффективно. Именно поэтому никакой раст и не мог бы существовать, как он и не существовал. Вернее он существовал, но в другом виде. И довольно долго. Правда никто реализовать его не мог.
А потом пришлось срочно всё менять и делать на llvm. По-сути создавая язык заново. Хотя это не язык, а набор никак не связанных друг с другом костылей/простых решений.
Фичи описанные в статье.
Покажите. К тому же компиляция компиляции рознь. Тоже самое и с метапрограммированием. Лисп и прочие подобные представители — это просто генерация уровня чуть выше текстовых шаблонов при крайне примитивных синтаксических/статических возможностях. С тех же 60/70 годах в си были макросы и это тоже формально метапрограммирование. Но уже давно никого не волнуют формальности, а волнуют нюансы.
Аналогично. Я столько слышал, но ни разу не видел. Покажите мне аналог constexpr, описанной статической рефлексии, шаблоны и прочее. Что-то уровня libclang и т.д.
Оно не было там обнаружено. Оно там было изначально. Обнаружено там было другое — расширенное использование и выход на компилтайм-вычисления.
И чем же оно принципиально ужасней лиспа? Вы сможете показать сравнения ужасностей?
Раст никоим образом не конкурент С++. Из метапрограммирования там только макросы с инопланетным синтаксисом, т.к. по-сути внешний язык(как и в си). По части же компилтайм-вычислений там вообще ничего нет. Начали пытаться добавлять какие-то зачатки constexpr.
Очевидно, что сделать банальную кодогенерацию на уровне чуть выше текстовой — проще. Несоизмеримо проще, чем добавить в язык мета-возможности. Но всё это просто внешние сущности со всеми вытекающими.
Его создатели осознали простую вещь — идти простым путём просто, а сложным сложно. И были выбраны везде и всюду простые пути. Можно сколько спорить на тему «почему был сделан такой выбор», но выбор этот сделан — это очевидно.
Ничего не понял. Что мешает загружать эти модули в С++-компилятор? Ничего. Это не имеет никакого отношения к языку. Это просто попытка разыграть карту «у нас один компилятор, а у вас много», но это глупо.
Где в расте какие-то мета-возможности? Зачем в мета-язык тащить аналог constexpr? Зачем там макросы на внешнем языке?
Да, это действительно так. В лиспе придерживались того же пути, той же практики — идти туда, где проще. К чему это привело — все знают. Лисп умер, а то что не умерло — преобразовалось в тот самый аналог С++. Но и его положение так же известно.
А чего вы взяли, что этот подход «разумный»? Какие этому есть основания? История лиспа? Это контр-пример.
К тому же, года к появлению раста имеют мало отношение. А что действительно имеет отношение — это С++ и развитие его инфраструктуры. И именно компилятор(llvm) и прочий рантайм позволил расту существовать. С++ подарил ту инфраструктуру — которая позволяет кому угодно(хоть студенту первого курса) сделать новый язык, который зарулит все те, которые существовали до.
Именно эти задачи и подходящие. Именно эти возможности и позволяю эффективно решать те самых подходящие задачи.
И получаем файл, т.к. спастил я цитату не полностью:
Здесь уточнение, как именно будет происходить вычисление «скалярного произведения» в «программу на Rust».
А что вы пытаетесь мне подсунуть?
Который вы только что придумали, но самом деле вы то имели ввиду другое, и я это знаю, и я это доказал выше.
Где вы написали на rust программу для «вычисления скалярного произведения векторов»? Я отвечу — нигде. Вы написали программу вызова си-функции из rust.
Я слушаю про внимательность и тому подобное.
Нет, это не будет вызовом кернела. Это доказано мною выше.
Это логика несостоятельна. К тому же, зачем задним числом пытаться что-то изменять? Пока у вас gpu_dot не вызвается из раста — всё эти рассуждения не имеют смысла, т.к. вы показывали не это.
Какое отношение к вызову си кода из раст имеет куда? Никакого. Как минимум вы должны написать «вызов си кода из раста НА ПРИМЕРЕ куды», но опять же — это будет полной глупостью, т.к. куда тут вообще не при делах.
Тоже самое и со сборкой. «сборка С++ кода через cargo на примере куда», но опять же — куда тут никаким образом не относится к теме.
Опять же, неверно. В статье не рассказывается как писать на С++ + cuda, а даже если бы и рассказывалось — причём тут раст? Так и пишите «как писать на С++ + cuda».
Я вам дам правильный заголовок. «пишем на С++ + cuda c» + «вызываем написанный таким образом код из раста». То, что написано у вас — неверно.
Это ничего не изменит.
Ну это принципиальный момент. По-сути из статьи можно выкинуть cuda и ничего не изменится, т.к. статья чисто про вызов сишной функции из раста.
Это просто вызов си-функции. Какая она — это неважно.
Я знаю, строчка упомянутая мною именно оттуда.
Это обычный сишный рантайм. К тому же это неважно, ведь даже если мы определяем по границе cuda, то границей является gpu_dot. И даже если принять вашу логику — кернелом будет gpu_dot, но вы её не вызываете — вы вызываете обёртку над gpu_dot.
Нельзя. Это вызов обёртки dot, которая вызывает обёртку, которая вызывает кернел. dot никоим образом не вызвает кернел.
Поэтому как это не называй — это обычный вызов сишной функции из раста. Этот вызов никак не связан с cuda, вообще никак.
Раст ничего никуда не подгружает. Проблема в отсутствии прописанных путей/кривой линковке. С растом это никак не связано.
А вызов кернела вот:
А где у вас вызов кернела из rust?