Wawancara dengan bapak bahasa Move: Mengapa bahasa kontrak pintar Sui Move cocok untuk membangun produk Web3?

Kami baru-baru ini berbicara dengan Sam Blackshear, CTO Mysten Labs dan pencipta bahasa pemrograman Move, tentang mengapa dia mengembangkan Sui Move, bahasa pemrograman kontrak cerdas baru, kemampuan yang dapat diperluas oleh Sui, dan dampak teknologi terdesentralisasi dalam membangun manfaat dari penerima.

Berikut isi wawancara tersebut:

**T1. Pertama, dapatkah Anda memberikan gambaran umum tentang apa itu bahasa pemrograman, kualitas apa yang paling dicari pengembang saat memilih bahasa pemrograman, dan apa yang mendorong Anda untuk mengembangkan bahasa pemrograman Anda sendiri? **

Bahasa pemrograman hanyalah alat untuk interaksi yang ramah, aman, efisien, dan jelas dengan komputer, dan ini sangat penting untuk komputer. Kita tidak dapat berkomunikasi dengan komputer dalam bahasa alami, karena seluruh makna bahasa alami adalah kaya dan ekspresif. Saat Anda menggunakan nada yang sedikit berbeda atau memilih cara yang agak berbeda untuk mengungkapkan kata-kata, kalimat atau paragraf Anda dapat memiliki arti yang sama sekali berbeda.

**Dalam bahasa pemrograman, hal terpenting adalah menentukan semantik dengan tepat. ** Saat Anda menulis sebuah program, Anda tahu apa yang akan dilakukannya. Jika Anda melakukan perubahan kecil, Anda tahu ke mana arah perubahan itu. Ini harus dipertahankan pada berbagai tingkatan, seperti Anda dapat menulis kode dalam bahasa sumber, memiliki arti, dan kemudian diterjemahkan ke dalam bentuk representasi lain, kemudian juga harus memiliki arti yang sama, hingga mencapai mesin. sama berlaku untuk modul pemrosesan.

**Saya pikir bahasa pemrograman bersifat khusus domain atau khusus tugas, tidak seperti bahasa alami. **Jika tidak, hanya dengan satu bahasa pemrograman, Anda dapat melakukan semuanya. Tetapi alasan ada banyak bahasa pemrograman adalah karena Anda tidak bisa mahir di semua bidang. Mereka mencoba menargetkan domain masalah tertentu dan fokus pada pemecahan masalah tersebut. Sebagai contoh, jika Anda melihat bahasa pemrograman Rust yang kami gunakan untuk menulis blockchain Sui dan sebagian besar pekerjaan sistem lain yang kami lakukan di Mysten, ini berfokus pada penulisan kode yang cepat dan berperforma tinggi sambil menjaga keamanan. Ini memberi Anda akses ke detail tingkat rendah seperti memori, struktur utas, atau konkurensi, tetapi tidak membiarkan Anda membuat kesalahan seperti bahasa sebelumnya seperti C atau C++.

Jadi kisah Move sangat mirip dengan itu. Saat saya membuatnya, itu bukan untuk membuat bahasa baru. Anda menyebutkan sebelumnya apa yang dicari pengembang dalam suatu bahasa. Mereka bertanya, "apakah bahasa ini bagus untuk apa yang saya coba capai?" Tapi saya pikir mungkin yang lebih penting, "*apakah bahasa ini memiliki komunitas yang besar? Apakah ada banyak basis data yang tersedia? Apakah banyak pemrogram yang menggunakannya? Apakah ada sumber daya pendidikan yang bagus? *" Ini sangat penting, jadi batasan untuk membuat bahasa baru harus sangat tinggi, meskipun bahasa itu sendiri lebih baik, tetapi jika tidak memiliki faktor-faktor ini, maka keuntungannya tidak ada artinya. Membangun komunitas yang besar dan bersemangat dari awal sangatlah sulit.

**T2、****Bisakah Anda berbagi lebih banyak tentang pengembangan Move? **

**Pindah berasal dari proyek Libra Facebook. **Tugas saya saat itu bukanlah membuat bahasa baru, tetapi untuk "Libra perlu memiliki kontrak pintar, jadi cari tahu apa yang harus kita lakukan." Saya melihat segala macam hal. Bisakah kita menggunakan Solidity di EVM? Haruskah kita menggunakan bahasa tujuan umum biasa, seperti WASM atau JVM, dan menggunakannya untuk Libra? Atau haruskah kita membuat sendiri?

Keputusan untuk membuat sesuatu milik kami sendiri didasarkan pada penelitian kontrak pintar yang ada, memahami apa yang coba dilakukan oleh pemrogram, dan di mana bahasa tertentu membantu mereka dan di mana mereka mengecewakannya. Kesimpulan saya adalah bahwa dalam banyak kasus, bahasa kontrak pintar yang ada mengecewakannya.

Ini jelas dari catatan keamanan Solidity yang buruk, tetapi yang lebih mendasar, kontrak pintar ini bukanlah jenis program yang sangat tradisional. Soliditas bukanlah bahasa yang dibangun untuk apa yang dilakukan orang sekarang. Saya tidak mengkritiknya karena ini adalah bahasa kontrak pintar pertama yang belum tahu apa yang orang ingin lakukan dengannya. Setelah Anda melihat apa yang orang coba lakukan dengannya, saya pikir jelas bahwa Anda memerlukan kumpulan abstraksi dan alat pemrograman yang berbeda yang tidak disediakan oleh bahasa Solidity.

Jadi kontrak pintar ini sangat sederhana, pada dasarnya mereka melakukan dua hal. Mereka menentukan jenis aset, termasuk aturan kapan aset dapat ditransfer, apa yang dapat Anda lakukan dengannya, siapa yang dapat membacanya, dan siapa yang dapat menulis surat kepada mereka**. **** Dan periksa kebijakan kontrol akses untuk menentukan siapa yang memiliki aset, siapa yang boleh menggunakannya, dan siapa yang boleh mengoperasikannya. **Semuanya berputar di sekitar aset, dan Anda ingin aset tersebut memiliki atribut yang sama dengan aset fisik. Jika saya menyerahkan sesuatu kepada Anda, maka Anda harus memilikinya dan saya tidak akan memilikinya lagi.

**Dalam kontrak pintar ada konsep kepemilikan dan pengalihan kepemilikan, tetapi di komputer semuanya hanya bit dan byte dan dapat disalin dengan bebas. **Dan, tahukah Anda, konsep-konsep ini tidak ada di dunia nyata. Jadi Anda menginginkan bahasa yang memberi Anda abstraksi yang baik tentang kepemilikan dan homogenisasi. Sama seperti di dunia nyata, tetapi tanpa memaksa pemrogram untuk menemukannya kembali. Anda menginginkan jaminan keamanan dasar.

Inilah yang dilakukan Move dan mengapa kami akhirnya membuat bahasa baru ini. Tugas-tugas ini sangat penting untuk pemrograman kontrak pintar. Mereka sulit untuk dibuat ulang dalam bahasa lain, termasuk bahasa kontrak pintar yang ada, dan kami ingin merancang seluruh bahasa untuk menyediakan fungsi dasar ini sehingga pemrogram dapat menulis kode dengan aman dan efisien tanpa harus menulis beberapa kode setiap kali mereka ingin. roda.

**Q3、****Sui menggunakan varian Move yang disebut Sui Move. Apa yang mendorong perubahan ini? Fitur Sui Move apa yang ideal untuk membuat produk di Web3? **

Beberapa faktor mendorong perubahan ini, salah satunya adalah tujuan proyek awal Libra untuk membangun jaringan pembayaran yang sesuai. Jadi kami mencoba merancang Move (sebagai bahasa tujuan umum. Tetapi kami juga melakukan beberapa hal secara sadar, karena Libra ingin memiliki batasan. Salah satu hal penting adalah mereka tidak ingin orang dapat mengirim aset tertentu ke di mana saja. Mereka ingin orang secara eksplisit membuat akun dan menetapkan beberapa aturan saat akun dibuat, seperti pemilik akun harus melalui verifikasi KYC. Atau mungkin ada biaya untuk membuat akun, atau hanya bisa dibuat oleh orang kecil dengan izin untuk membuat akun Beberapa orang membuat akun. Karena seluruh tujuan Libra adalah untuk melakukan pembayaran yang sesuai dan kontrak pintar yang sesuai, ada batasan ini. Namun di dunia Web3 yang lebih umum, justru sebaliknya. Anda tidak ingin patuh pada tingkat dasar, Ini adalah konsep kontrak pintar. Anda ingin segala sesuatunya sebebas mungkin, sangat mungkin mengirim sesuatu ke alamat mana pun. Maka Anda seharusnya tidak membuat akun secara eksplisit karena yang akan memblokir berbagai kasus penggunaan. Ini merupakan faktor penting.

Faktor lainnya adalah meskipun kami fokus pada aset di Move, pada saat di Libra kami tidak memikirkan cara membawa fokus aset ke dalam transaksi itu sendiri. Jadi saat Anda masuk ke tingkat transaksi, Anda masih memiliki API ini, tempat Anda memasukkan angka dan boolean dan hal-hal yang bukan aset, lalu di Move, Anda menggunakan angka tersebut untuk menarik aset dari akun dan melakukan hal lain. Ternyata sebagian besar kode yang Anda jalankan adalah pembukuan yang buruk untuk mengeluarkan benda ini, mengeluarkan benda itu, mengeluarkan sesuatu yang lain, dan ok, saya memiliki semua aset yang saya inginkan. Ini dia, di studio saya, dan sekarang saya bisa mulai melakukan sesuatu yang berarti. Dan kemudian di akhir proses, Anda mungkin berkata, "Oke, masukkan kembali aset itu ke akun ini, masukkan kembali ke akun itu, atur ulang.

Di Sui, kami telah memikirkannya, jika setiap program dimulai dan diakhiri seperti ini, dapatkah kami memisahkannya? Jadi, logika untuk memproses transaksi akan melakukannya untuk programmer, dan dari sudut pandang programmer, mereka hanya memiliki aset yang mereka butuhkan dan mulai melakukan pekerjaan yang menarik segera. Ini adalah model data objek-sentris **** yang ada di Sui. **Di Move asli, kami memiliki model data berbasis akun, aset disimpan di bawah akun, dan pemrogram harus mengekstraknya secara eksplisit. Di Sui, saat mereka memasuki bagian Pindahkan dari transaksi, aset telah diperoleh oleh runtime Sui. Ini lebih nyaman bagi pemrogram karena mereka tidak perlu melakukan semua ini sebelum dan sesudah pembukuan, dan ini juga memungkinkan kita untuk menentukan apakah kita dapat menjalankan satu transaksi secara paralel dengan yang lain tanpa benar-benar mengeksekusinya. beberapa hal lain yang lebih efisien.

Kami juga telah melakukan beberapa pekerjaan lain yang sangat menarik, seperti memanfaatkan model data berbasis objek untuk blok transaksi yang dapat diprogram. Ini adalah topik yang agak teknis yang dengan senang hati akan saya diskusikan secara mendalam. Namun kedua faktor tersebut adalah pendorong utama perbedaan dari Move yang asli.

Q4、** Bisakah Anda berbagi informasi lebih lanjut tentang blok transaksi yang dapat diprogram dan fungsinya? **

Saya suka menggunakan analogi untuk menjelaskan bahwa blockchain lainnya seperti pujasera di pusat perbelanjaan. Anda ingin es krim, Anda pergi ke kios es krim, mengeluarkan kartu kredit Anda dan membayar. Tetapi jika Anda memutuskan masih menginginkan burger, maka Anda pergi ke kedai burger dan membayar lagi. Saya bukan pelahap, tetapi jika saya ingin makan delapan hal, saya harus melakukan delapan transaksi terpisah. **Di mana Sui lebih merupakan prasmanan, setiap transaksi lebih dari satu hal. Setelah Anda membayar prasmanan, ada banyak hal yang dapat Anda lakukan tanpa biaya tambahan. **Kamu bisa makan es krim, kamu bisa makan burger, kamu bisa mencampur semuanya.

Untuk membuat konsep ini sedikit lebih konkret, dalam kasus sederhana, jika Anda mengirim 100 transaksi untuk mencetak 100 NFT, Anda dapat mengirim transaksi yang menghasilkan 100 NFT. Biaya seperti itu hampir sama dengan biaya pencetakan NFT. Anda juga dapat melakukan pengemasan transaksi yang heterogen, seperti transaksi pertama dalam satu blok mengambil karakter Mario dari dompet multisig Anda, dan transaksi kedua meminta Mario, yang kemudian memungkinkan Anda memainkan game tersebut. Jika Anda memenangkan permainan dan mendapatkan piala, mungkin perdagangan ketiga meletakkan piala di lemari piala yang Anda bagikan dengan teman. **Apa yang keren adalah bahwa blok transaksi yang dapat diprogram memungkinkan pemrogram untuk menulis kode sedemikian rupa sehingga permainan tidak perlu tahu tentang dompet multisig atau bagaimana Mario disimpan, juga tidak perlu tahu tentang lemari piala Anda atau bagaimana penerapannya . **

** Blok transaksi yang dapat diprogram terdiri dari transaksi dengan objek input dan output. **Jika Anda membutuhkan objek input, Anda bisa mendapatkan objek itu tanpa peduli dari mana asalnya, dan meneruskan outputnya ke objek yang membutuhkannya, dan juga tidak peduli ke mana objek tersebut diteruskan. Di blockchain lain, koplingnya lebih kuat, jadi game harus berintegrasi dengan dompet multisig dan loker trofi, atau semuanya harus mengimplementasikan beberapa antarmuka umum dan memiliki kopling yang lebih kuat. **Sui membuat apa yang disebut kombinasi ad-hoc jauh lebih mudah. **Seperti, jika pipanya cocok, kita bisa melakukannya dalam satu transaksi.

**Q5、****Apa keuntungan dari blok transaksi yang dapat diprogram untuk pengguna? **

Bagi pengguna, manfaat dari blok transaksi yang dapat diprogram termasuk biaya bahan bakar yang lebih rendah, karena Anda dapat mengemas semua operasi ke dalam satu transaksi alih-alih melakukan transaksi terpisah. Selain itu, memerlukan lebih sedikit persetujuan. Jika Anda menggunakan sistem yang memerlukan persetujuan transaksi, Anda hanya perlu melakukannya sekali, lalu melakukan semuanya sekaligus. Manfaat lainnya adalah atomicity, jika Anda ingin melakukan tiga hal berbeda dan ingin operasi ketiga berhasil hanya jika dua operasi pertama berhasil, jika operasi tersebut harus transaksi independen, maka Anda tidak dapat mewujudkannya. Namun, jika Anda dapat menempatkan semuanya dalam satu transaksi, maka Anda dapat dengan mudah mencapainya.

**Q6, **** Saya pernah mendengar Anda dan orang lain berbicara tentang pengembangan di Sui sebagai pengalaman hebat bagi pemrogram dan ini penting. Apakah Anda memiliki anekdot untuk dibagikan kepada pemrogram Web3 berpengalaman dan baru yang memulai dengan Sui Move? **

Bagi para pengembang yang berasal dari bahasa pemrograman Web3 lain, pengalaman pengembangan mereka di Move dan Sui Move memang lebih efisien dan aman. Saya baru saja membuat podcast tentang Bucket Protocol dan mereka sedang membangun proyek DeFi yang sangat keren di Sui. Saat mereka mendemonstrasikan arsitektur sistem, mereka menjelaskan bagaimana komponen yang berbeda bekerja sama. Mereka mengatakan bahwa jika mereka menulis proyek ini dalam Solidity, mungkin butuh delapan bulan, tetapi dengan Sui Move hanya butuh dua bulan, dan mereka sangat yakin dengan keamanannya. Cara kerja bahasanya sangat dekat dengan ide portofolio proyek di kepala mereka. Di dunia Solidity, koneksinya kurang langsung.

Ini hanyalah satu contoh, tetapi kami mendengar banyak kasus serupa di mana orang mengatakan bahwa mereka berkembang lebih cepat dalam bahasa dan merasa lebih percaya diri setelah selesai. Itu membuat saya senang mendengarnya. Namun di satu sisi, ini tidak mengherankan, kami melihat Soliditas dan mempelajari masalahnya. Kami secara eksplisit merancang skenario seputar cara membuatnya lebih aman dan lebih cepat. Kami melihat apa yang coba dilakukan oleh pengembang bahasa, dan bagaimana mendesain bahasa untuk memenuhi kebutuhan mereka, daripada memenuhi apa yang sudah ada. Bahasa dirancang untuk masalah yang dimiliki orang, jadi ketika mereka beralih, mereka sangat menghargai bahasa tersebut.

**Mereka mengatakan keuntungan penggerak pertama itu penting, tetapi saya kira dalam kasus ini, keuntungan penggerak terlambatlah yang lebih penting. **

Itu benar, itu saja.

**T7、****Anda telah menyentuh ini ketika Anda menyebutkan Sui Move dan keseluruhan fitur berorientasi objek Sui. Tapi bisakah Anda mengartikulasikan dengan lebih jelas hubungan antara desain Sui Move dan kemampuan Sui untuk mencapai adopsi massal Web3, latensi rendah, biaya rendah, dan skalabilitas? **

Salah satu hal yang sangat kami waspadai untuk berkontribusi pada Sui, dan masalah yang dihadapi platform lain, adalah jika Anda memiliki kapasitas terbatas, apakah itu seperti 15 transaksi per detik (TPS) seperti Ethereum atau 100 atau 1.000 transaksi, jika angka tetap, maka ketika platform menjadi terlalu sukses, itu akan mencapai batas atas kapasitas. Pada titik ini, pengalaman semua orang yang menggunakan platform ini menurun. Jika hanya ada 1.000 lowongan, Anda harus memilih 1.000 yang paling penting, yang dapat dipilih melalui penawaran gas atau metode lainnya. Secara keseluruhan, harga gas akan meningkat, latensi akan meningkat, atau keduanya. Banyak kasus penggunaan dikecualikan, karena hanya mereka yang mampu membayar biaya tertinggi yang akan berhasil, sementara yang lain harus mencari di tempat lain atau menunggu lebih lama. Ini bukan situasi yang baik.

**Sui menargetkan skalabilitas horizontal. **Jumlah throughput tertentu dapat dicapai jika sejumlah perangkat keras dialokasikan. Jika diperlukan lebih banyak throughput, validator dapat memperkenalkan lebih banyak fasilitas perangkat keras, tanpa batas atas. Beginilah cara kerja setiap layanan Web2. Maksud saya, ada beberapa kendala teknik yang harus Anda atasi, ini bukan hal yang pasti atau mudah dilakukan, tetapi semua orang ingin mencapai skalabilitas horizontal saat merancang layanan web yang dapat diskalakan.

Jika Sui memiliki lebih banyak pelanggan atau pengguna, tujuan kami adalah agar Sui terus berkembang dan semuanya akan berfungsi. Tentu saja, sambil mempertahankan latensi yang sangat rendah. Anda tidak ingin mengorbankan latensi sambil meningkatkan throughput.

Dalam sistem Libra, karakteristik ini tidak dipertimbangkan. Ini hanya sistem pembayaran skala kecil, dengan ratusan operator pembayaran, dan mungkin ada puluhan juta pembayaran per hari, tetapi tidak lebih. Jadi kami mengadopsi arsitektur kotak tunggal, yang lebih sederhana dan memadai. Namun di Sui, kita tahu bahwa sistem Libra tidak akan berfungsi karena tidak memiliki fitur skalabilitas horizontal. Jadi kami berpikir, bagaimana kami mendesain sistem dari awal yang bisa melakukan itu. Di sinilah model data berorientasi objek masuk. Kami pada dasarnya membuang model data berbasis akun lama karena sangat sulit untuk mencapai skalabilitas horizontal. Sebaliknya, jika Anda mengatur semuanya menjadi objek, status global hanyalah satu peta besar dari ID objek ke objek. Ini adalah penyimpanan nilai kunci, dan kami tahu cara menskalakan penyimpanan nilai kunci, ini adalah masalah teknik yang sederhana.

Pertanyaannya kemudian, bagaimana kita mendesain struktur transaksi yang mengakomodasi pengambilan dan pembaruan data dari key-value store? Bagaimana kita menghancurkan penyimpanan nilai kunci? Bagaimana kita memutuskan di mana transaksi harus diproses? Itu pada dasarnya dari mana asalnya. Meskipun demikian, kami tahu cara mengukur hal-hal ini. Bagaimana kami mengubahnya menjadi sesuatu yang memiliki properti blockchain, pembacaan yang dapat diverifikasi, bekerja dengan Move, dll. Lalu bagaimana menyatukan mereka semulus mungkin.

Q8、** Di tingkat yang lebih tinggi, bagaimana Anda mendiskusikan potensi teknologi terdesentralisasi dengan pengembang yang skeptis terhadap Web2? **

**Saya pikir blockchain dan cryptocurrency pada dasarnya adalah teknologi yang menghilangkan friksi. **Ada hambatan yang sangat mempersulit kami untuk melakukan transaksi keuangan, membangun aplikasi, atau menyiapkan informasi karena informasi tidak dapat melewati hambatan tersebut, atau jika melewati hambatan tersebut, memerlukan bantuan beberapa pihak ketiga, dan ini pertama Pihak ketiga mengenakan biaya untuk dapat memberikan bantuan.

Contoh klasik yang suka digunakan orang adalah membeli rumah. Ada pembeli dan penjual, tetapi ketika Anda benar-benar melakukan pembayaran, harus ada agen escrow yang tidak melakukan apa-apa selain duduk di sana dan menyimpan dana karena pembeli dan penjual tidak sepenuhnya percaya satu sama lain. Ini adalah fakta kehidupan. Kita akan berurusan dengan ini. Namun, jika agen escrow dapat berupa kode yang dapat dilihat oleh kedua belah pihak, atau diverifikasi oleh pihak ketiga, maka agen escrow tersebut dapat melakukan pekerjaan tersebut secara gratis atau lebih murah. Tujuan blockchain bukan untuk menghilangkan agen escrow di real estat. Ini hanyalah salah satu kasus penggunaan, tetapi sering terjadi.

**Jika tidak ada penghalang interoperabilitas antara aplikasi A dan aplikasi B lagi, tetapi dibangun di atas platform dasar yang sama, sehingga Anda dapat membuat berbagai hal mengalir dari satu aplikasi ke aplikasi lainnya, baik itu item dalam aplikasi, data, lintas promosi, atau ketiga -produk pesta dibangun di atas keduanya. **Atau bayangkan Internet, tempat situs web berbagi data satu sama lain, tetapi ini hanyalah metadata yang hanya dapat dibaca. Bagaimana jika ini bisa menjadi mata uang? Atau mungkinkah itu barang yang bisa dibuang? Atau mungkinkah program loyalitas dan kupon? Semuanya memiliki fungsi ini bawaan. Ini sangat abstrak, tapi disitulah letak potensinya. Biasanya, orang yang sedang membangun akan menganggap ini sebagai kekuatan super baru yang dapat dia gunakan untuk membangun sesuatu yang lebih menarik.

Q9、** Untuk pengguna akhir, meskipun mereka tidak memiliki pengetahuan teknis, apakah Anda merasa ragu ketika mereka mempertimbangkan kepercayaan kode, meskipun opsi lainnya adalah entitas pusat besar yang buram? **

Saya rasa tidak. Karena kita melakukan hal seperti ini setiap hari, bukan? Ketika saya masuk ke email saya, saya tidak khawatir kode tersebut akan menghapus salah satu email saya, atau ketika saya mengirim email, itu tidak benar-benar mengirimkannya. Jika itu terjadi, saya mungkin akan berhenti menggunakan email, atau menggunakan penyedia lain. Saya pikir ini sangat mirip, tentu saja tidak semua orang bisa membaca sesuatu dan memeriksa cara kerjanya.

Dan, Anda tahu, jika saya ingin memeriksa kode emailnya, saya tidak bisa karena kodenya tidak ada. Jadi transparansi adalah aspek penting dari itu. Meskipun tidak semua orang dapat melakukan ini, beberapa orang dapat mengambil sampelnya. Dan, gabungkan itu dengan penggunaan kembali apa pun, plus kekekalan. Itulah kuncinya di sini. Ketika saya masuk ke email saya, saya tidak tahu apakah kodenya telah berubah sejak terakhir kali saya melakukan sesuatu. Tidak ada transparansi tentang ini. Bahkan mengetahui informasi ini, Anda bisa mendapatkannya di Web3, dan Anda tidak bisa mendapatkannya di tempat lain.

**Q10、****Apa harapan Anda untuk pengembangan Sui Move di masa mendatang? **

**Banyak fitur yang saat ini kami fokuskan didasarkan pada pengalaman kami dengan pengembang yang merilis batch awal paket Sui Move mereka, dan kemudian melihat bagaimana mereka ingin mengembangkan fitur tersebut, mana yang mudah dikembangkan, dan mana yang lain lebih sulit. **Sui Move adalah bahasa yang bagus untuk paket rilis pertama, tetapi untuk jenis yang akan saya ubah, saya akan menambahkan beberapa bidang, saya akan menambahkan beberapa fungsi, saya akan melakukannya dengan cara yang kohesif tetapi tidak bertentangan dengan penggunaan paket awal Untuk beroperasi dengan cara yang dipercaya pengguna, ini menjadi masalah yang sangat menantang. Banyak hal yang kami lakukan adalah melihat ini dan menentukan fitur tingkat bahasa apa yang dapat kami tambahkan yang memberi programmer fleksibilitas untuk memperluas sambil mempertahankan kepercayaan pengguna kode asli.

** Kami sedang mengerjakan banyak fitur yang terkait dengan ini, terutama tipe enum. **Kami juga melakukan banyak pekerjaan untuk meningkatkan pengalaman menghubungkan Move dengan kode front-end. Kami sering bercanda bahwa tipikal aplikasi Sui adalah 5% kode Pindah dan 95% kode front-end. Jadi kami sangat fokus pada 95% itu. Kami menghabiskan banyak waktu membicarakan tentang Move, tetapi kami juga banyak berfokus untuk membuat bagian lain lebih efisien dan membuat koneksi lebih mudah. Secara umum, kami sangat fokus pada bagaimana membuat aplikasi lebih terdiri dari Move untuk keamanan lebih. Pada saat yang sama, bagaimana kita membuat 95% kode tersebut dapat dimengerti oleh programmer Move dan programmer non-Move.