Pasé suficiente tiempo trabajando con herramientas de smart contracts como para desconfiar de todo lo que diga "menos boilerplate". Normalmente solo significa que el boilerplate se ha movido a algún lugar que todavía no he encontrado.
Por eso Dusk Forge llamó mi atención. No porque haga que Rust de repente sea fácil, sino porque ataca una irritación concreta: escribir un contrato nativo de Dusk suele implicar gestionar el contrato en sí, sus exports WASM, los esquemas y la capa data-driver que permite que las apps se comuniquen con él. El macro #[contract] de Forge genera todo eso a partir de un solo módulo en lugar de obligar al desarrollador a mantenerlo por separado.
Sobre el papel, eso parece algo pequeño. En la práctica, la fricción pequeña decide qué se construye. He visto cadenas con modelos de ejecución elegantes perder desarrolladores porque el flujo de trabajo del día a día se sentía como un castigo. La idea central estaba bien. La mecánica, no.
Pero hay un detalle. La abstracción oculta la complejidad; no la elimina. Un esquema generado es útil hasta que se desincroniza. Un data-driver es cómodo hasta que la versión del frontend, la wallet, el nodo y el contrato dejan de ponerse de acuerdo. La documentación propia de Dusk admite que desarrollar con un DuskVM nativo aún implica herramientas específicas de Dusk, mientras que EVM te da el ecosistema más amplio de Ethereum.
Así que no leo Forge como un avance. Lo leo como trabajo de mantenimiento. Después de suficientes ciclos, confío más en el trabajo de mantenimiento que en un lenguaje supuestamente revolucionario.
La liquidez no le importa lo elegante que se vea la expansión del macro. Los usuarios se preocupan por si la app funciona y por si la salida es aburrida.
Tal vez esa sea la parte que vale la pena observar: no si Forge suena más fácil, sino si construir sobre Dusk se vuelve más barato en las formas invisibles.
@Dusk #dusk $DUSK
Por eso Dusk Forge llamó mi atención. No porque haga que Rust de repente sea fácil, sino porque ataca una irritación concreta: escribir un contrato nativo de Dusk suele implicar gestionar el contrato en sí, sus exports WASM, los esquemas y la capa data-driver que permite que las apps se comuniquen con él. El macro #[contract] de Forge genera todo eso a partir de un solo módulo en lugar de obligar al desarrollador a mantenerlo por separado.
Sobre el papel, eso parece algo pequeño. En la práctica, la fricción pequeña decide qué se construye. He visto cadenas con modelos de ejecución elegantes perder desarrolladores porque el flujo de trabajo del día a día se sentía como un castigo. La idea central estaba bien. La mecánica, no.
Pero hay un detalle. La abstracción oculta la complejidad; no la elimina. Un esquema generado es útil hasta que se desincroniza. Un data-driver es cómodo hasta que la versión del frontend, la wallet, el nodo y el contrato dejan de ponerse de acuerdo. La documentación propia de Dusk admite que desarrollar con un DuskVM nativo aún implica herramientas específicas de Dusk, mientras que EVM te da el ecosistema más amplio de Ethereum.
Así que no leo Forge como un avance. Lo leo como trabajo de mantenimiento. Después de suficientes ciclos, confío más en el trabajo de mantenimiento que en un lenguaje supuestamente revolucionario.
La liquidez no le importa lo elegante que se vea la expansión del macro. Los usuarios se preocupan por si la app funciona y por si la salida es aburrida.
Tal vez esa sea la parte que vale la pena observar: no si Forge suena más fácil, sino si construir sobre Dusk se vuelve más barato en las formas invisibles.
@Dusk #dusk $DUSK
