Saya menghabiskan cukup banyak waktu di sekitar alat smart-contract untuk menjadi curiga pada apa pun yang bilang “lebih sedikit boilerplate”. Biasanya itu cuma berarti boilerplate-nya dipindahkan ke tempat lain yang belum pernah saya temukan.
Itulah sebabnya Dusk Forge menarik perhatian saya. Bukan karena membuat Rust tiba-tiba jadi mudah, tetapi karena menyerang iritasi yang spesifik: menulis kontrak native Dusk biasanya berarti harus menangani kontraknya sendiri, ekspor WASM-nya, skema, dan lapisan data-driver yang memungkinkan aplikasi berbicara dengannya. Macro #[contract] dari Forge menghasilkan semuanya dari satu modul, bukan membuat pengembang memeliharanya secara terpisah.
Secara teori, itu kecil. Dalam praktiknya, gesekan kecil menentukan apa yang jadi dibangun. Saya pernah melihat rantai dengan model eksekusi yang rapi kehilangan pengembang karena alur kerja harian terasa seperti hukuman. Ide dasarnya bagus. Mekaniknya tidak.
Tapi ada tangkapannya. Abstraksi menyembunyikan kompleksitas, bukan menghapusnya. Skema yang dihasilkan itu berguna sampai skema itu mulai melenceng. Data-driver itu nyaman sampai versi frontend, wallet, node, dan kontrak tidak lagi cocok satu sama lain. Dokumentasi resmi Dusk mengakui bahwa pengembangan native DuskVM tetap berarti tooling yang spesifik Dusk, sementara EVM memberi Anda ekosistem Ethereum yang lebih luas.
Jadi saya tidak membaca Forge sebagai terobosan. Saya membacanya sebagai pekerjaan pemeliharaan. Setelah melewati cukup banyak siklus, saya lebih percaya pekerjaan pemeliharaan daripada bahasa yang terdengar “terobosan”.
Likuiditas tidak peduli seberapa elok tampilan perluasan macro-nya. Pengguna peduli apakah aplikasinya bekerja, apakah “jalan keluarnya” membosankan.
Mungkin bagian yang patut diawasi adalah itu—bukan apakah Forge terdengar lebih mudah, tapi apakah membangun di Dusk jadi lebih murah lewat cara-cara yang tak terlihat.
@Dusk #dusk $DUSK
Itulah sebabnya Dusk Forge menarik perhatian saya. Bukan karena membuat Rust tiba-tiba jadi mudah, tetapi karena menyerang iritasi yang spesifik: menulis kontrak native Dusk biasanya berarti harus menangani kontraknya sendiri, ekspor WASM-nya, skema, dan lapisan data-driver yang memungkinkan aplikasi berbicara dengannya. Macro #[contract] dari Forge menghasilkan semuanya dari satu modul, bukan membuat pengembang memeliharanya secara terpisah.
Secara teori, itu kecil. Dalam praktiknya, gesekan kecil menentukan apa yang jadi dibangun. Saya pernah melihat rantai dengan model eksekusi yang rapi kehilangan pengembang karena alur kerja harian terasa seperti hukuman. Ide dasarnya bagus. Mekaniknya tidak.
Tapi ada tangkapannya. Abstraksi menyembunyikan kompleksitas, bukan menghapusnya. Skema yang dihasilkan itu berguna sampai skema itu mulai melenceng. Data-driver itu nyaman sampai versi frontend, wallet, node, dan kontrak tidak lagi cocok satu sama lain. Dokumentasi resmi Dusk mengakui bahwa pengembangan native DuskVM tetap berarti tooling yang spesifik Dusk, sementara EVM memberi Anda ekosistem Ethereum yang lebih luas.
Jadi saya tidak membaca Forge sebagai terobosan. Saya membacanya sebagai pekerjaan pemeliharaan. Setelah melewati cukup banyak siklus, saya lebih percaya pekerjaan pemeliharaan daripada bahasa yang terdengar “terobosan”.
Likuiditas tidak peduli seberapa elok tampilan perluasan macro-nya. Pengguna peduli apakah aplikasinya bekerja, apakah “jalan keluarnya” membosankan.
Mungkin bagian yang patut diawasi adalah itu—bukan apakah Forge terdengar lebih mudah, tapi apakah membangun di Dusk jadi lebih murah lewat cara-cara yang tak terlihat.
@Dusk #dusk $DUSK
