Я достаточно долго поработал с инструментами для смарт-контрактов, чтобы начать подозревать все, что говорит «меньше boilerplate». Обычно это значит, что boilerplate просто переехал туда, где я пока его не нашёл.
Именно поэтому мне в глаза попалась Dusk Forge. Не потому, что она внезапно делает Rust простым, а потому что она бьёт в конкретную раздражающую точку: написание нативного контракта Dusk обычно означает работу с самим контрактом, его WASM-экспортами, схемами и слоем data-driver, который позволяет приложениям с ним общаться. Макрос Forge #[contract] генерирует всё это из одного модуля вместо того, чтобы заставлять разработчика поддерживать всё отдельно.
На бумаге это немного. На практике решает небольшое трение — то, что определяет, что вообще будет сделано. Я видел сети с элегантными моделями выполнения, которые теряли разработчиков, потому что ежедневный рабочий процесс воспринимался как наказание. Идея была хорошей. Механика — нет.
Но есть подвох. Абстракция скрывает сложность, но не устраняет её. Сгенерированная схема полезна, пока не начнёт дрейфовать. Data-driver удобен, пока фронтенд, кошелёк, node и версии контракта не перестанут совпадать. В собственных документах Dusk признают, что разработка нативного DuskVM всё равно подразумевает Dusk-специфичные инструменты, тогда как EVM даёт доступ к более широкому Ethereum-экосистеме.
Так что я не читаю Forge как прорыв. Я читаю её как работу по сопровождению. После достаточно долгого числа циклов я больше доверяю работам по поддержке, чем «языку прорыва».
Ликвидности всё равно, насколько элегантно выглядит разворачивание макроса. Пользователей волнует, работает ли приложение, и будет ли выход спокойным.
Возможно, именно это и стоит наблюдать — не звучит ли Forge проще, а то, насколько дешевле становится разработка на Dusk во всех невидимых смыслах.

@Dusk #dusk $DUSK