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

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

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

Утрировано, вы задаете шаблон, запускаете команду "go:gen" и ваша кодовая база расширяется нужным кодом

Из преисуществ: результат намного безопаснее, понятнее и виднее, можно кастомизировать реузльтат, позволяет из шаблонов релизовать невероятно оптимизированные алгоритмы и многое другое

JS тебе дали еще один шанс, а ты все по тем же граблям... тьфу ты блять...

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

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

Макросы же наоборот лучше подходят ЯП с нормальной системой типов. 🙂 async/await как раз это самое.

А вообще, давай уже похороним Бун. Зачем нам ещё один рантайм? 🥸

В том то и дело, что разработчики Го намерено выбрали кодогенерацию следуя принципу "явности и простоты": написал шаблон, сгенерил код, проверил его, покрыл тестами и пошел дальше

Макросы в этом плане ближе к "магии и абстракции" (да, есть и у них фишки, но кодогенерация на мой взгляд нужнее и полезнее)

Важно отметить, что макросы и "синтаксический сахар", который может потом после компиляции превращаться во что-то другое, это разные вещи (и я не против "сахара")

Я не могу назвать "async / await" макросами, это просто часть языка, или я неправильно понял?

А Бун наоборот пусть живет и развивается: только если Node почувствует, что запахло жаренным они начнут шевелиться (а то, в последних двух мажорных релизах у нас появился только встроенный jest и fetch... убого)

> Я не могу назвать "async / await" макросами, это просто часть языка, или я неправильно понял?

async/await сахар внутри превращается в обычные .then() цепочки. Согласись, что как-то страно, что нельзя также делать для других типов данных?

Например для Promise<Option<T>> было бы удобно «await» сразу значение T.

Так было раньше, теперь async await является операторами языка

Чем для меня отличается "сахар" – тем, что его разрабатывают люди, задача которых создавать компиляцию и этот самый сахар и добавить какую-то новую фичу могут только контрибьюторы

А если дать макросы кому-угодно, то с ними и будут делать что угодно, в итоге приведя к тому о чем стонут С++ разработчики (то есть куче неуправляемых макросов)

Ты имеешь ввиду, чтобы из функции возвращалось "T", вместо "Promise<Option<T>>"?

Да, макросы могут навредить. Но, в JS полно практик, которые сообщество успешно исжило. Перестали же делать monkey patching.

Скорее, чтобы после await возвращался тип T или вся функция делала return Option.none, если нету значения. Чтобы мне самому не надо было писать if (Option.isNone(result)) { return Option.none }.

Типа такой штуки.

https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions

Сообществу Node.js я очень слабо доверяю – многие являются выходцами из frontend мира, пришли, чтобы пописать на блокчейнах или пилят стартап на MongoDB + NestJS

Поэтому всегда очень боюсь давать лишнее людям, которым не доверяю (опять же, это лично мой подход, поэтому я люблю Go)

Но мысль понимаю

И вот тут опять же лично про мой подход: люблю только явные прямолинейные реализации)

Я лучше тысячу раз напишу if (Option.isNone(result)) { return Option.none }, чем буду использовать какую-либо кастомную неявную конструкцию

Но это чисто мое мнение, тут каждый выбирает то, что ему удобно

Поэтому да, если тебе помогла бы такая конструкция, то макросы будут полезны

А для меня они опасны)

Давай так: если такой оператор (например !, в Zig, кстати тоже !) будет сначала частью компилятора TS, а потом частью языка, то я только за (как async / await когда-то)

А вот если это будет кастомным макросом, который написали на каком-то месте работы, я бы побоялся этого

Боюсь, этого никогда не будет. 🥲

Ну, кстати, да, понимаю

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