Где происходит сборка макросов?
Во время компиляции и только. Никаких перезаписей на диск, доп. файлов и так далее. Я уже рассказывал про аугментацию, благодаря которой это возможно.

Как отлавливаются ошибки при сборке?
Тут есть два поведения - анализатора и компилятора.
Анализатор прогоняет ваш код через код макроса и выдаст вам ошибку, которую сам макрос может вернуть. Она с подробным описанием, а значит вы сможете её понять и исправить.
Компилятор игнорит возвращаемые ошибки макросов и просто не соберёт их. Если макрос выдаёт ошибку, но нигде не используется - проект соберётся без него.

Как пишется макрос?
В многом процесс похож на написание build_runner для классов: Вам даётся ClassDeclaration и TypeDefinitionBuilder, где первым вы "определяетесь", а вторым рисуете ваш сгенерированный код.

JsonCodable уже можно использовать?
Нет. Текущий флаг - Experimental, реализация этого макроса сделана для примера. Пока что вы не сможете сигнорировать на нём некоторые поля, поменять стиль названий переменных и т.д., что может dart:convert.

Какие есть даты выпуска?
Выпуск макросов обещают к концу 2024 года. Написание макросов внутри sdk обещается к 2025, но начнётся раньше, поэтому к концу года точно сможем посмотреть ещё парочку.

Убьёт ли это build_runner?
Пока нет. И не уверен, что должно. И вижу в этом две причины:
1) На build_runner очень много кода уже написано и сгенерировано.
2) Макросы не могут трогать ничего дальше классов, в то время как build_runner мог трогать файлы другого формата! (assets_gen, graphql_codegen, retrofit и остальные)

Презентацию Google не смотрел. Мне хватило сокращенной версии.

Суть, вроде бы, передана максимально полно.

Последние два дня думаю только об одном, что выразили в этом issue.

Cutting the stateful boilerplate #148241

TLDR: "А почему бы нам не заиспользовать макросы для генерации виджетов? Это же позволит сделать нам код короче! (см. приложение)"

Точнее я не думаю о том, чтоб код стал чище или короче... (не пытаемся снова оптимизировать строчки и байтики, нет).
Я думаю про то, что как только макросы выйдут в stable, мы увидим с ними очень много разной сложности решений.

Будут State Management решения, похожие на @State из SwiftUI (MobX со своими @observable и @action как раз повторяют эту историю).
Будут DI решения, где Injectable полноценно превратят в котлиновский dagger.
И, как уже видим, попытки упростить и так простые вещи, как создание и менедмжент виджетов.

Хорошо ли это? Я не знаю. Уверен, мы увидим как множество крутых и новых идей, так и макросный GetX 5.

Причём я говорю это достаточно рано, когда большая часть разработчиков библиотек ещё не смотрит на реализацию через макросы. Посмотрим через год-полтора, насколько я буду прав 👀

Чтож, теперь мне это приснится.. 😿

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

Давно хотел это сделать, но никак не мог объяснить себе - зачем и почему? Долго размышлял, пытался осмыслить, но не выходило. Решился. Результат не кусает и не волнует, а значит в этом глупом действии я увидел гораздо больше смысла, чем есть на самом деле.

ВКонтакте для меня как часть прошлого. Когда ещё школьником ты с друзьями перекидывался постами, списывался в чатах, отправлял подарки по праздникам. Я не застал “стену”, уж достаточно поздно пришёл, но застал старый дизайн и флэш игры. Для меня это тоже часть истории, да и место, с которым я хотел бы ассоциировать себя и своё “социальное” детство.

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