Ich habe lange genug mit Smart-Contract-Tools gearbeitet, um bei allem misstrauisch zu werden, das „weniger Boilerplate“ verspricht. Meist heißt das nur, dass sich die Boilerplate irgendwohin verschoben hat, das ich noch nicht gefunden habe.
Deshalb hat mich Dusk Forge aufmerksam gemacht. Nicht, weil es Rust plötzlich einfach macht, sondern weil es eine ganz bestimmte Nervigkeit angeht: Einen nativen Dusk-Contract zu schreiben heißt normalerweise, den Contract selbst zu handhaben – seine WASM-Exports, Schemata und die Data-Driver-Schicht, die es Apps ermöglicht, mit ihm zu sprechen. Das Forge-Makro #[contract] generiert all das aus einem einzigen Modul, statt den Entwicklern aufzubürden, es getrennt zu pflegen.
Auf dem Papier ist das klein. In der Praxis entscheidet kleine Reibung darüber, was gebaut wird. Ich habe bereits Chains mit eleganten Ausführungsmodellen gesehen, die Entwickler verloren haben, weil der tägliche Workflow sich wie eine Bestrafung anfühlte. Die Grundidee war gut. Die Mechanik nicht.
Aber da ist ein Haken. Abstraktion versteckt Komplexität, entfernt sie nicht. Ein generiertes Schema ist nützlich, bis es „driftet“. Ein Data-Driver ist praktisch, bis Frontend, Wallet, Node und Contract-Versionen nicht mehr zueinander passen. Die eigenen Dusk-Dokumente geben zu, dass nativer DuskVM-Entwickler-Work immer noch dusk-spezifische Tools bedeutet, während EVM dir das breitere Ethereum-Ökosystem gibt.
Also sehe ich Forge nicht als Durchbruch. Ich sehe es als Wartungsarbeit. Nach genug Zyklen vertraue ich Wartungsarbeit eher als „Breakthrough“-Sprache.
Liquidität kümmert sich nicht darum, wie elegant die Makro-Expansion aussieht. Nutzer kümmern sich darum, ob die App funktioniert – und ob der Exit langweilig ist.
Vielleicht ist das der Teil, den man beobachten sollte: nicht, ob Forge sich leichter anhört, sondern ob der Aufbau auf Dusk in den unsichtbaren Formen billiger wird.
@Dusk #dusk $DUSK
Deshalb hat mich Dusk Forge aufmerksam gemacht. Nicht, weil es Rust plötzlich einfach macht, sondern weil es eine ganz bestimmte Nervigkeit angeht: Einen nativen Dusk-Contract zu schreiben heißt normalerweise, den Contract selbst zu handhaben – seine WASM-Exports, Schemata und die Data-Driver-Schicht, die es Apps ermöglicht, mit ihm zu sprechen. Das Forge-Makro #[contract] generiert all das aus einem einzigen Modul, statt den Entwicklern aufzubürden, es getrennt zu pflegen.
Auf dem Papier ist das klein. In der Praxis entscheidet kleine Reibung darüber, was gebaut wird. Ich habe bereits Chains mit eleganten Ausführungsmodellen gesehen, die Entwickler verloren haben, weil der tägliche Workflow sich wie eine Bestrafung anfühlte. Die Grundidee war gut. Die Mechanik nicht.
Aber da ist ein Haken. Abstraktion versteckt Komplexität, entfernt sie nicht. Ein generiertes Schema ist nützlich, bis es „driftet“. Ein Data-Driver ist praktisch, bis Frontend, Wallet, Node und Contract-Versionen nicht mehr zueinander passen. Die eigenen Dusk-Dokumente geben zu, dass nativer DuskVM-Entwickler-Work immer noch dusk-spezifische Tools bedeutet, während EVM dir das breitere Ethereum-Ökosystem gibt.
Also sehe ich Forge nicht als Durchbruch. Ich sehe es als Wartungsarbeit. Nach genug Zyklen vertraue ich Wartungsarbeit eher als „Breakthrough“-Sprache.
Liquidität kümmert sich nicht darum, wie elegant die Makro-Expansion aussieht. Nutzer kümmern sich darum, ob die App funktioniert – und ob der Exit langweilig ist.
Vielleicht ist das der Teil, den man beobachten sollte: nicht, ob Forge sich leichter anhört, sondern ob der Aufbau auf Dusk in den unsichtbaren Formen billiger wird.
@Dusk #dusk $DUSK
