Неужели и goto ненужно?! :}

Препроцессоры и кодогенераторы нельзя срастить со средой исполнения.

forth

Препроцессоры и кодогенераторы нельзя срастить со средой исполнения.

forth

И CL.

JetBrains Nemerle 2

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

JetBrains Nemerle 2

А вот это хорошая новость...

гы, pdf

Using a hierarchy of Domain Specific Languages in complex software systems design
V. S. Lugovsky
(Submitted on 9 Sep 2004)
A new design methodology is introduced, with some examples on building Domain Specific Languages hierarchy on top of Scheme.
Comments:	8 pages, 1 figure
Subjects:	Programming Languages (cs.PL); Data Structures and Algorithms (cs.DS); Software Engineering (cs.SE)
ACM classes:	D.1.1;I.2.2;D.3.2;D.2.10
Cite as:	arXiv:cs/0409016v1 [cs.PL]
Submission history
From: Vitaly Lugovsky [view email] 
[v1] Thu, 9 Sep 2004 01:44:05 GMT (18kb)

А вообще, http://ru.wikipedia.org/wiki/Метапрограммирование

Есть правда, один маленький несущественный нюанс...

.NET only?

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

Это свойство называется homoiconicity.

Семейств языков, обладающих этим свойством, человечество на данный момент придумало крайне мало: Lisp (Common Lisp, Scheme, Racket, Clojure) Forth, и его ответвления, вроде Factor(помесь Lisp и Forth) Prolog Tcl

слабать на скорую руку какую нить хрень

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

Не знаком с Racket... Чем круче, в двух словах? Но subst и eval тоже творят чудеса, особенно при умелом обращении с неймспейсами и алиасами.

...с человеческой платформой и поддержкой.
Есть правда, один маленький несущественный нюанс...

.NET only?

Анон нынче какой-то односторонний пошёл, все пишет, пишет что-то, да вот только не читает.

Эффективные — это когда лишние три процента времени выполнения с помощью лома и такой-то матери уменьшают до двух процентов?

Нет, это в сотни раз и более быстрее чем тупорылые интерпретаторы. Вот сам подумай, что быстрее - parsec-образное тормозное нечто или скомпилированный автомат?

На кой делать из лишпа недопаскаль, если и так есть нормальный Паскаль?

А много есть задач для которых могут понадобиться компилируемые eDSL?

Таких задач большинство.

Компилируемый eDSL заведомо лучше любого интерпретируемого (кацкелисты дружно затыкаются и идут мимо). Потому как с компиляцией мы на халяву получаем и отладчик, и поддержку от IDE, и вменяемые сообщения об ошибках, и статический анализ, и много чего еще.

Интерпретаторов вообще быть не должно. Но тупым функциональщикам этого никогда не понять.

Лол, ты дебил.

Нет, дебил таки ты.

При чем тут парсер, если мы говорим о генерации, а не о разборе?

При том, что именно парсер должен понимать конструкции вида ` бла-бла-бла ,хня ,@другаяхня `, где бла-бла-бла разворачивается в конструктор AST.

Таких задач большинство.

Если бы их было большинство, то большинство языков были бы гомоиконными с поддержкой развитого метапрограммирования (допустим, что первое необходимо для второго). Я с ходу могу вспомнить только генерацию кода реализующего КА для заданного регулярного выражения - чтобы это был именно embedded DSL нужна метасистема в языке, и тут действительно будет выигрыш в производительности порядкового уровня.

Интерпретаторов вообще быть не должно. Но тупым функциональщикам этого никогда не понять.

Ок, очень доходчиво объясняешь :) Главное - аргументированно. Только при чём тут «кацкелисты» и функциональщики - непонятно. Хранение разной структурированной информации (для которой часто можно даже BNF расписать) в виде структур/классов и их интерпретация с помощью функций/методов где только ни применяется.

А чтобы избавиться от интерпретаторов нужно либо писать кучу бакендов под множество архитектур для целевого языка, либо иметь целевой компилируемый (для множества архитектур) язык с метапрограммированием (чтобы можно было компилировать в него), либо хорошие language agnostic VM (вроде LLVM + ещё что-то для high level).

Ролвно настолько же толсто, на сколько был толст твой оригинальный высер.

Хранение разной структурированной информации (для которой часто можно даже BNF расписать) в виде структур/классов и их интерпретация с помощью функций/методов где только ни применяется.

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

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

Тут тебе и человеческое метапрограммирование

К сожалению - нету. Вообще «по-человечески» срастить метапрограммирование с другими системами типов невозможно. То есть вообще никак. Так что если ЯП статичиски типзиирован, то сразу можно скзаать - никакого человеческого метапрограммирования для того ЯП нет и не будет никогда.

метапрограммирование - это всегда «слабать на скорую руку».

Это в том случае, когда система метапрограммирования - говно. В других случаях метапрограммирование применяют как раз тогда, когда нужно наиболее надежное решение.

Если бы их было большинство, то большинство языков были бы гомоиконными с поддержкой развитого метапрограммирования

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

Хранение разной структурированной информации (для которой часто можно даже BNF расписать) в виде структур/классов и их интерпретация с помощью функций/методов где только ни применяется.

Хранение информации в компайлтайме, ее интерпретация, изменение и использование с целью модификации - тоже где только не применяется. В любом статически типизированном ЯП, по крайней мере :)

При том, что именно парсер должен понимать конструкции вида ` бла-бла-бла ,хня ,@другаяхня `, где бла-бла-бла разворачивается в конструктор AST.

Еще раз - ПРИ ЧЕМ ТУТ ПАРСЕР если речь была о генерации выражений, дебил? При помощи конструкций вида ` бла-бла-бла ,хня ,@другаяхня ` невозможно построить АСТ произвольного вида, всегда найдется случай, когда надо будет пидорасить АСТ вручную. Если язык негомоиконичен, то, как в случае немерле, АСТ строить вручную приходится уже в случае простейших АСТ, это подтверждается примерами. Я все еще жду ссылок на сложные макросы в немерле без перепидорашивания АСТ и на макросы, генерирующие макросы. Хотя я уже привык к тому, что немрелебляди только пиздят да жопой крутят - ничего толкового в ответ дождаться от них нельзя в принципе.

Тут дело не столько в эффективности сколько в том, что ДСЛ раскрывается в момент компайлтайма.

Только еДСЛ. Если говорить про ДСЛ vs еДСЛ, то мне вспоминается отдельно реализованный на С++ DSL (td) из LLVM, который компилируется в С++ же при сборке самого LLVM, и eDSL на макросах из SBCL который раскрывается в CL во время компиляции SBCL - оба решают одну и ту же задачу (более-менее декларативное описание архитектур с их инструкциями), но, на мой взгляд, в LLVM всё выглядит специфичнее и чище. К тому же, тот DSL из LLVM можно, в принципе, унаследовать, он независим, а eDSL из SBCL использует произвольный код на CL зависимый при этом от других частей SBCL, то есть он полезен только внутри SBCL.

Вообще, следует верно определить понятие «метапрограммирование».

(Мета)трансляция расширенного языка в расширяемый язык средствами самого языка :) Если технически, то это цитирование (удобно получать из любого выражения языка объект синтаксического типа), работа с синтаксическими объектами (конструкторы, аккессоры), макросы как функции (и определяемые так же) из одних синтаксических объектов в другие (из любых объектов в любые, если любому выражению соответствует синтаксический объект), экспандер, использующий макросы во время компиляции и аппликация макросов (которая может выглядеть как обычная аппликация или как-то иначе).

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

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

Это просто compile-time транслятор из языка в язык же. Понятно, что таким образом можно достроить язык ограниченный какой-то системой типов, просто как один из возможных трансляторов. Но это будет уже другой язык который можно написать и отдельно, затратив при этом примерно те же усилия (+ парсер, принтер, дебаггер, REPL... по мере необходимости). Чтобы ограничить сам язык (например, CL) нужно ещё ему code walker с type checkerом написать - для другого динамического языка это бы решилось дописыванием реализации безо всякого метапрограммирования. Опять те же усилия и довольно редкая задача.

В этом контесте понятно, что «интерпретируемое метапрограммирование» - оксюморон из разряда «статическая система типов в рантайме».

Ну да, речь шла о том что типичный способ решения ряда задач это написание, косвенно, «языка» и «интерпретатора», то есть не метапрограммирование. Вопрос в том какие именно задачи требуют компиляции расширенного языка в расширяемый и нужно ли это вообще в «нормальном ЯП».

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

OCaml, F#, Scala? И то с фундаментальной точки зрения всё плоды 70-ых, разве что в Scala есть что-то от зависимых типов.

Хранение информации в компайлтайме, ее интерпретация, изменение и использование с целью модификации - тоже где только не применяется.

Одно дело система типов, другое - абсолютно любое преобразование чего-то записанного типичным для языка образом в примитивные выражения этого же языка. Системы типов гораздо специфичнее, они решают проблему отбрасывания программ которые не удовлетворяют определённым условиям.

немрелебляди

Хм, а какое $LANGUAGE_NAME не рифмуется с $LANGUAGE_NAMEбляди по твоему, не подскажешь?

Только еДСЛ.

О нем и речь. Просто я по привычке букву е опускаю.

но, на мой взгляд, в LLVM всё выглядит специфичнее и чище.

Ну что же вы хотели от слабенькой макросистемы CL? Действительно, по сравнению с ней и сторонние препроцессоры не так плохи.

Это просто compile-time транслятор из языка в язык же.

В том и дело, что нет. Если бы это был «просто транслятор» он бы ничем не отличался принципиально от стороннего препроцессора. Этот препроцессор вам не сможет распарсить грамматику реализованного на макросах ДСЛ, потому что эта грамматика будет контекстно-зависима, да еще и самомодифицируема во время разбора :) У вас в корне неверное понимание метапрограммирования, вы подходите с точки зрения синтаксиса- то есть взяли некую программу, распарсили в соответствии с определенной грамматикой, построили некий АСТ, все. Это верно для примитивных систем метапрограммирования, тех же внешних препроцессоров, но в корне не верно для систем развитых. Там подход в корне иной - следует идти от семантических правил. Рассуждения следует вести не в терминах АСТ и его преобразований, а в терминах лексического контекста и взаимодействия с ним. То есть не «парсим, преобразовываем, генерим», а «вносим информацию в лексический контекст, получаем к ней доступ снизу по контексту, выполняем некие действия». То, что внесение инфы в контекст и «выполнение некоторых действий» происходит при помощи генерации некоего АСТ - не принципиально. Работа с АСТ тут - _метод_, а не самоцель. Мы просто работаем с синтаксическим окружением, а макросы - это просто некий слой абстракции. Ну когда мы хотим инкапсулировать некоторую часть рантайм логики приложения - мы пишем функцию. Когда мы хотим инкапсулировать некоторую часть логики взаимодействия с лексическим контекстом - мы пишем макрос. Условно говоря - всегда, когда во время компиляции мы имеем дело с лексическим контекстом, можно утверждать, что тут работает макрос. Любые системы типов, многие оптимизации - все это макросы.

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

Мы уже обсуждали этот вопрос. Если средства метапрограммирования в ЯП не развиты, зато средства написания, косвенно, «языка» и «интерпретатора» - развиты, то, естественно, следует предпочесть второй вариант. Под «развиты» понимается не только абстрактная мощность, но и практическое удобство использования. Если инструмент есть, но неудобен - никто, естественно, не будет его использовать. Но чем удобнее будет становиться этот инструмент - тем бОльшую часть задач, решаемых до тэого другими инструментами, он будет перетягивать на себя (естественно, если инструмент достаточно мощен, чтобы в принципе решить эту задачу - сомнительно, что вы сумеете открутить гайку отверткой).

Вопрос в том какие именно задачи требуют компиляции расширенного языка в расширяемый и нужно ли это вообще в «нормальном ЯП».

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

OCaml, F#, Scala? И то с фундаментальной точки зрения всё плоды 70-ых, разве что в Scala есть что-то от зависимых типов.

Ну вот именно - только сейчас внедряют плоды 70-х.

Одно дело система типов, другое - абсолютно любое преобразование чего-то записанного типичным для языка образом в примитивные выражения этого же языка.

Еще раз - рассуждайте о метапрограммировании не как о «парсим АСТ - генерим АСТ», а как о «внедряем информацию в лексический контекст - меняем семантику программы». Система типов в данном случае «внедряем информацию о типах - если все плохо меняем семантику на вывод эррора»

Все рифмуются. И это прекрасно, ящитаю. Иное было бы нечестным, вы не находите?

Ну что же вы хотели от слабенькой макросистемы CL?

А где она сильная (почти SUBJ)?

Если бы это был «просто транслятор» он бы ничем не отличался принципиально от стороннего препроцессора.

Раз это транслятор «из языка в язык же», естественно, что он цикличный, замкнут на контекст и т.п. «просто транслятор» это параллель, имеется в виду, что можно решать все те задачи что решаются с помощью трансляторов, но ещё иметь уже рабочую среду в дополнение - парсер, принтер, дебаггер, REPL. То есть параллель именно с системами типов мне неочевидна, с трансляторами вообще (тайп чекеры в том числе, оптимизации и т.д.) - да.

Любые системы типов, многие оптимизации - все это макросы.

_Может_ быть реализовано макросами, но не обязательно.

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

Если нет ключа или пассатижей - можно поставить отвёртку рядом с гранью и ударить молотком :)

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

Event loop (в том числе прерывания и таймер), в частности IO bus (которую с большим скрипом, со слов Брукса, вводили в 60-ые), конкурентность с сообщениями, базы данных, сетевые протоколы - множество всего что не укладывается в концепцию голой тьюринг-полной машины, но что необходимо и имеет свои формальные модели. Ну и под словом «задача» я подразумеваю нечто конкретное, типа «десять задач которые лучше всего решать на brainfuck - [discurs]», а не общее место о тьюринг-полноте brainfuckа (при отсутствии всего остального, опуская ещё годный toolchain, биндинги, библиотеки, наличие комьюнити и прочие уже не технические вопросы).

Groovy уже предлагали? Только ты не увлекайся, у меня обычно метапрограммирование используется в одной из 10 задач, при чем ранее я ее решал другим способ и только потом узнал как удобнее сделать через метасистему. В большом проекте ведет к непониманию между разработчиками, т.к непривычно.

Семейств языков, обладающих этим свойством, человечество на данный момент придумало крайне мало: Lisp (Common Lisp, Scheme, Racket, Clojure) Forth, и его ответвления, вроде Factor(помесь Lisp и Forth) Prolog Tcl

В этих перечислениях вечно забывают Io. А он гораздо более достоин упоминания, чем, скажем, Tcl и Forth. :}

Раз это транслятор «из языка в язык же», естественно, что он цикличный, замкнут на контекст и т.п. «просто транслятор» это параллель, имеется в виду, что можно решать все те задачи что решаются с помощью трансляторов

Это утверждение из разряда «все задачи решаются на любой тьюринг-полном ЯП». То есть никакого прауктического смысла в нем нет.

То есть параллель именно с системами типов мне неочевидна, с трансляторами вообще (тайп чекеры в том числе, оптимизации и т.д.) - да.

Про какую паралель идет речь? Я не говорил о паралелях, я говорил о том, что метапрограммирование - это взаимодействией с контекстом и изменение семантики программы, основываясь на этом контексте. Отсюда, любая система типов - метапрограммирование. Любой тайпчекер - не более чем набор макросов стандартной библиотеки.

_Может_ быть реализовано макросами, но не обязательно.

Любой тайпчекер - это работающие во время компайлтайма функции, которые взаимодействуют с лексическим контекстом прграммы и меняют ее семантику, верно? Но ведь такие «функции» - это и етсь макросы! :)

Если нет ключа или пассатижей - можно поставить отвёртку рядом с гранью и ударить молотком :)

Это ежели молоток есть, а коли нет? :) Камень с земли подберете? В любом случае - аналогию вы поняли :)

Event loop (в том числе прерывания и таймер), в частности IO bus (которую с большим скрипом, со слов Брукса, вводили в 60-ые), конкурентность с сообщениями, базы данных, сетевые протоколы - множество всего что не укладывается в концепцию голой тьюринг-полной машины, но что необходимо и имеет свои формальные модели.

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

Ну и под словом «задача» я подразумеваю нечто конкретное, типа «десять задач которые лучше всего решать на brainfuck - [discurs]», а не общее место о тьюринг-полноте brainfuckа (при отсутствии всего остального, опуская ещё годный toolchain, биндинги, библиотеки, наличие комьюнити и прочие уже не технические вопросы).

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

все задачи решаются на любой тьюринг-полном ЯП

На любом тьюринг-полном ЯП можно решить любую задачу

Да нет же. Только разные калькулятивные задачи. Грубо говоря, тьюринг-полный ЯП это процессор с памятью, безо всех остальных контроллеров, ну или, если более абстрактно, какое-нибудь нетипизированное лямбда исчисление, без ввода-вывода, событий, событий по времени, параллельного выполнения, сообщений.

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

Мне не совсем это понятно (такой опыт сложился, может, если бы мне попались не «слабенькие» макросистемы...). Я смотрю на макросы как на _инструмент_ делать AST -> AST, то есть как на способ задать встроенный транслятор из языка (расширенного) в сам язык (расширяемый). Может это и упрощённо - не знаю. Например, есть некий код (foo (bar (baz ...))) в языке семантика которого толком не определена (?). Далее, в зависимости от того что представляют собой определения foo, bar и baz данный код будет приобретать ту или иную семантику. Как-то так? Совсем не понятно как формально рассуждать о языке без фиксированной (классически) семантики.

Отсюда, любая система типов - метапрограммирование.

Любая система типов - объект программирования.

Любой тайпчекер - не более чем набор макросов стандартной библиотеки.

Любой тайпчекер - не более чем набор функций реализации (интерпретатора/компилятора).

Но ведь такие «функции» - это и етсь макросы!

Только в узком кругу :) Обычно компилятор это просто программа с просто функциями. Конечно, в среде с метациклическим компилятором всё сложнее.

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

Практически, мне из виденного понравился внешний транслятор из LLVM. Про тьюринг-полноту вообще лучше не заводить разговор, я думаю (слишком общее место).

Не знаком с Racket... Чем круче, в двух словах?

Quick: An Introduction to Racket with Pictures

Но subst и eval тоже творят чудеса, особенно при умелом обращении с неймспейсами и алиасами.

Не спорю, фан определенный есть.

Кто на твоей аватарке?

Нет, это в сотни раз и более быстрее чем тупорылые интерпретаторы. Вот сам подумай, что быстрее - parsec-образное тормозное нечто или скомпилированный автомат?

Parsec — не интерпретатор, вообще-то, так что наезд мимо тазика.

Ролвно настолько же толсто, на сколько был толст твой оригинальный высер.

Нет, конечно.

Да нет же. Только разные калькулятивные задачи.

Любую задачу можно выразить в калькулятивной форме.

Я смотрю на макросы как на _инструмент_ делать AST -> AST

И это в корне неверно. Точнее верно - но для простейших макросов, либо для примитивных систем метапрограммирования. Если система мтеапрограммирования достаточно мощна, то макросы - это инструмент для взаимодействия с лексическим окружением и переопределения сементики программы. Собственно эта задача (взаимодействие с окружением и переопределение семантики) просто _решается за счет_ преобразования АСТ -> АСТ. На самом деле она, в принципе, могла бы решаться и по-другому.

Как-то так? Совсем не понятно как формально рассуждать о языке без фиксированной (классически) семантики.

Но если мы добавим набор семантических правил (макросы - в некотором смысле они и есть), то семантика становится определенной, так? Тут просто суть в том, что эти правила создаются и могут переопределяться на ходу (в рамках компапйлтайма, ессно).

Любая система типов - объект программирования.

В каком смысле?

Любой тайпчекер - не более чем набор функций реализации (интерпретатора/компилятора).

Ну да. О чем и речь.

Только в узком кругу :)

В каком смысле в узком кругу? Это, по сути, определение макроса.

Обычно компилятор это просто программа с просто функциями.

Это если рассматривать ее отдельно от программы, которую он компилируют. Если же компилятор и компилируемая программа «живут» в рамках единой среды...

Практически, мне из виденного понравился внешний транслятор из LLVM.

Если задача была решена внешним транслятором - значит это очень простая с точки зрения метапрограммирования задача. Тривиальная, я бы даже сказал :)

Тордендаль

Любую задачу можно выразить в калькулятивной форме.

Но так никто не делает (можно посмотреть на языки и API ОС).

В каком смысле?

Убрал приставку «мета» за ненадобностью. Вот есть в каком-нибудь компиляторе система типов для исходного языка, какое тут метапрограммирование?

В каком смысле в узком кругу?

В таком, что функции компилятора отвечающие за тайпчек никто не называет макросами, как и соответствующие системы типов - метапрограммированием.

Тривиальная, я бы даже сказал :)

http://llvm.org/docs/TableGenFundamentals.html. Интересно было посмотреть на что-нибудь нетривиальное.

ты не в теме, и, походу, графоманишь просто так.

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

Какой именно?

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

я бы поинтересовался для начала - ЧТО именно собирается писать ТС, для чего ему нужен такой язык и откуда такие требования

GNU Autotools - вообще крайний, маниакальный вариант метапрограммирования

Нет такого языка autotools, есть m4

Какой именно?

Nemerle 2 (aka JetBrains N2) пока есть только в спеках.

А вот это хорошая новость...

Запил на jvm не анонсирован, не говоря уже о реализации компиляции в нейтив.

VladD2:

по-этому

anonymous:

по-этому

Залогинься уже :)

с жесткими ограничениями макросистемы

Например?

Запил на jvm не анонсирован, не говоря уже о реализации компиляции в нейтив.

Если сам язык станет жить и развиваться под опекой JetBrains - это само по себе хорошо.