Move dilinin babasıyla röportaj: Sui Move akıllı sözleşme dili neden Web3 ürünleri oluşturmak için uygundur?

Geçenlerde Mysten Labs CTO'su ve Move programlama dilinin yaratıcısı Sam Blackshear ile yeni bir akıllı sözleşme programlama dili olan Sui Move'u neden geliştirdiği, Sui'nin genişletebileceği yetenekler ve merkezi olmayan teknolojinin fayda sağlama üzerindeki etkisi hakkında konuştuk. alıcının

Bu röportajın içeriği şöyle:

**S1. Öncelikle, bir programlama dilinin ne olduğu, geliştiricilerin bir programlama dili seçerken en çok hangi nitelikleri aradıkları ve sizi kendi programlama dilinizi geliştirmeye iten şeyler hakkında genel bir bilgi verebilir misiniz? **

Programlama dili, bilgisayarlarla samimi, güvenli, verimli ve net etkileşim için yalnızca bir araçtır ki bu özellikle bilgisayarlar için önemlidir. Bilgisayarlarla doğal dilde iletişim kuramayız çünkü doğal dilin tüm anlamı zengin ve anlamlı olmaktır. Biraz farklı bir ton kullandığınızda veya sözcükleri ifade etmek için incelikle farklı yollar seçtiğinizde, cümleniz veya paragrafınız tamamen farklı bir anlama gelebilir.

**Programlama dillerinde en önemli şey, kesin olarak tanımlanmış semantiklere sahip olmaktır. **Bir program yazdığınızda, ne yapacağını bilirsiniz. Üzerinde küçük ince ayarlar yaparsanız, bu değişikliğin nereye gideceğini bilirsiniz. Bu, birden çok düzeyde sürdürülmelidir, örneğin bir kaynak dilde kod yazabilirsiniz, bunun bir anlamı vardır ve daha sonra diğer temsil biçimlerine çevrilir, sonra aynı anlama gelir, ta ki makineye ulaşana kadar. aynı işlem modülleri için de geçerli.

**Programlama dillerinin, doğal dillerin aksine, doğası gereği etki alanına özgü veya göreve özgü olduğunu düşünüyorum. **Aksi takdirde tek bir programlama dili ile hepsini yapabilirsiniz. Ancak birden fazla programlama dili olmasının nedeni, her alanda iyi olamamanızdır. Belirli sorun alanlarını hedeflemeye ve bu sorunları çözmeye odaklanmaya çalışıyorlar. Örnek olarak, Sui blok zincirini yazmak için kullandığımız Rust programlama diline ve Mysten'de yaptığımız diğer sistem işlerinin çoğuna bakarsanız, güvenliği korurken hem hızlı hem de performanslı kod yazmaya odaklanır. Bellek, iş parçacığı yapıları veya eşzamanlılık gibi alt düzey ayrıntılara erişmenizi sağlar, ancak C veya C++ gibi önceki diller gibi hata yapmanıza izin vermez.

Yani Move'un hikayesi buna çok benziyor. Onu yarattığımda, yeni bir dil yaratmak değildi. Geliştiricilerin bir dilde ne aradığından daha önce bahsetmiştiniz. "Bu dil, başarmaya çalıştığım şey için doğru mu?" diye soruyorlar. iyi eğitim kaynakları var mı? *" Bunlar çok önemli, bu nedenle dilin kendisi daha iyi olsa bile yeni bir dil yaratma çıtası çok yüksek olmalıdır, ancak bu faktörlere sahip değilse, o zaman avantajı anlamsızdır. Sıfırdan büyük ve canlı bir topluluk oluşturmak çok zordur.

**S2、****Move'nin geliştirilmesi hakkında daha fazla bilgi paylaşabilir misiniz? **

**Hareket, Facebook'un Libra projesinden kaynaklanmaktadır. **O zamanki görevim yeni bir dil yaratmak değil, "Terazi'nin akıllı sözleşmelere ihtiyacı var, öyleyse ne yapmamız gerektiğini bulun." Her türlü şeye baktım. Solidity'i EVM'de kullanabilir miyiz? WASM veya JVM gibi düzenli bir genel amaçlı dil alıp Libra için kullanmalı mıyız? Yoksa kendimizinkini mi yaratmalıyız?

Kendimize ait bir şey yaratma kararı, programcıların ne yapmaya çalıştığını ve belirli dillerin onlara nerede yardımcı olduğunu ve onları nerede hayal kırıklığına uğrattığını anlamak için mevcut akıllı sözleşmeler üzerine yapılan araştırmalara dayanıyordu. Benim sonucum, çoğu durumda mevcut akıllı sözleşme dillerinin onları hayal kırıklığına uğrattığıdır.

Bu, Solidity'nin zayıf güvenlik sicilinden açıkça görülüyor, ancak daha temelde, bu akıllı sözleşmeler çok geleneksel program türleri değil. Sağlamlık, insanların şu anda yaptıkları için oluşturulmuş bir dil değildir. İnsanların onunla ne yapmak istediğini henüz bilmeyen ilk akıllı sözleşme dili olduğu için eleştirmiyorum. İnsanların bununla ne yapmaya çalıştığını gördüğünüzde, Solidity dilinin sağlamadığı farklı soyutlamalara ve programlama araçlarına ihtiyacınız olduğunu düşünüyorum.

Yani bu akıllı sözleşmeler çok basit, temelde iki şey yapıyorlar. Varlıkların ne zaman aktarılabileceği, onlarla neler yapabileceğiniz, bunları kimlerin okuyabileceği ve onlara kimlerin yazabileceği ile ilgili kurallar da dahil olmak üzere varlık türlerini tanımlarlar**. **** Varlığın kime ait olduğunu, kimlerin onu kullanmasına izin verildiğini ve üzerinde kimlerin işlem yapmasına izin verildiğini belirlemek için erişim kontrol politikasını kontrol edin. **Her şey varlıkların etrafında döner ve bu varlıkların fiziksel varlıklarla aynı özelliklere sahip olmasını istersiniz. Sana bir şey verirsem, o zaman senin alman gerekir ve artık bende olmaz.

**Akıllı sözleşmelerde mülkiyet kavramı ve mülkiyet devri vardır, ancak bir bilgisayarda her şey sadece bit ve bayttır ve özgürce kopyalanabilir. **Ve bilirsiniz, bu kavramlar gerçek dünyada yoktur. Yani, size mülkiyet ve homojenleştirme hakkında iyi soyutlamalar sağlayan bir dil istiyorsunuz. Tıpkı gerçek dünyada olduğu gibi, ancak programcıları onu yeniden icat etmeye zorlamadan. Temel güvenlik garantileri istiyorsunuz.

Move'un yaptığı budur ve bu yüzden bu yeni dili oluşturduk. Bu görevler, akıllı sözleşme programlaması için temeldir. Mevcut akıllı sözleşme dilleri de dahil olmak üzere diğer dillerde yeniden oluşturulması zordur ve tüm dili bu temel işlevleri sağlayacak şekilde tasarlamak istiyoruz, böylece programcılar her ikisi de yeniden icat etmek istediklerinde bazı kodlar yazmak zorunda kalmadan güvenli ve verimli bir şekilde kod yazabilirler. tekerlek.

**Q3、****Sui, Move'un Sui Move adlı bir varyantını kullanır. Bu değişikliklere ne sebep oldu? Sui Move'un hangi özellikleri Web3'te ürün oluşturmak için idealdir? **

Bu değişiklikleri yönlendiren birkaç faktör vardı; bunlardan biri, orijinal Libra projesinin uyumlu bir ödeme ağı oluşturma hedefiydi. Bu yüzden Move'u (genel amaçlı bir dil olarak) tasarlamaya çalıştık. Ancak bazı şeyleri bilinçli olarak da yaptık çünkü Libra kısıtlamalara sahip olmak istiyor. Önemli şeylerden biri, insanların belirli varlıkları gönderebilmesini istememeleri. İnsanların açıkça bir hesap oluşturmasını ve hesap oluşturulurken bazı kurallar koymasını isterler, örneğin hesap sahibinin KYC doğrulamasından geçmesi gerekir. Veya hesabı oluşturmak için bir ücret olabilir veya yalnızca hesap oluşturma izni olan küçük bir kişi tarafından oluşturulmuştur Bazı insanlar hesap oluşturur. Libra'nın tüm amacı uyumlu ödemeler ve uyumlu akıllı sözleşmeler yapmak olduğundan, bu sınırlamalar vardır. Ancak daha genel Web3 dünyasında, tam tersidir. temel düzeyde uyumlu olmak istemiyorum, Bu akıllı sözleşmelerin konseptidir. Her şeyin mümkün olduğunca ücretsiz olmasını istiyorsunuz, herhangi bir adrese bir şey göndermek mükemmel bir şekilde mümkün. O zaman açık bir hesap oluşturmamalısınız çünkü Bu, çeşitli kullanım durumlarını engelleyecektir.Bu önemli bir faktördür.

Diğer bir faktör de, Move'da varlıklara odaklanırken, o zamanlar Libra'da varlıkların odağını işlemin kendisine nasıl getireceğimizi düşünmemiş olmamızdır. Dolayısıyla, işlem düzeyine geldiğinizde, sayıları, boolean'ları ve varlık olmayan şeyleri girdiğiniz bu API'ye sahip olursunuz ve ardından Move'da bu sayıları hesaplardan varlıkları çekmek ve başka şeyler yapmak için kullanırsınız. Görünüşe göre çalıştırdığınız kodun çoğu, bu şeyi çıkarmanın, o şeyi çıkarmanın, başka bir şeyi çıkarmanın bu iğrenç muhasebesi ve tamam, istediğim tüm varlıklara sahibim. İşte buradalar, benim stüdyomda ve artık anlamlı bir şeyler yapmaya başlayabilirim. Ve sürecin sonunda, "Tamam, bu varlıkları tekrar bu hesaba koyun, tekrar o hesaba koyun, yeniden düzenleyin.

Sui'de, her program bu şekilde başlar ve biterse, onu soyutlayabilir miyiz diye düşündük. Dolayısıyla, işlemi işleme mantığı programcı için yapacaktır ve programcının bakış açısına göre, ihtiyaç duydukları varlıkları hazırlar ve ilginç işi hemen yapmaya başlarlar. Bu, Sui'de bulunan **** nesne merkezli veri modelidir. **Orijinal Move'da hesap tabanlı bir veri modelimiz vardı, varlıklar hesaplar altında saklanıyordu ve programcıların bunları açık bir şekilde ayıklaması gerekiyordu. Sui'de, işlemin Move kısmına girdiklerinde, varlıklar zaten Sui runtime tarafından satın alınmıştır. Bu, programcılar için daha uygundur, çünkü tüm bunları defter tutmadan önce ve sonra yapmaları gerekmez ve aynı zamanda bir işlemi gerçekten yürütmeden diğerine paralel olarak çalıştırıp çalıştıramayacağımızı belirlememizi sağlar.Sui'nin yatay ölçekleme için gizli sosu ve birkaç şey daha verimli.

Programlanabilir işlem blokları için nesne tabanlı bir veri modelinden yararlanmak gibi gerçekten ilginç başka işler de yaptık. Bu, derinlemesine tartışmaktan mutluluk duyduğum biraz teknik bir konu. Ancak bu iki faktör, orijinal Move'dan uzaklaşmanın ana itici güçleriydi.

**S4、****Programlanabilir işlem blokları ve işlevleri hakkında daha fazla bilgi paylaşabilir misiniz? **

Diğer blok zincirlerinin bir alışveriş merkezindeki yemek alanı gibi olduğunu açıklamak için bir benzetme kullanmayı seviyorum. Dondurma istiyorsun, dondurmacıya gidiyorsun, kredi kartını çıkarıyorsun ve ödüyorsun. Ama yine de bir burger istediğinize karar verirseniz, burger tezgahına gidip tekrar ödersiniz. Obur değilim ama sekiz şey yemek istersem, sekiz ayrı işlem yapmam gerekir. **Sui'nin daha çok bir açık büfe olduğu yerde, her anlaşma bir şeyden daha fazlasıdır. Büfe için ödeme yaptıktan sonra, ekstra ücret ödemeden yapabileceğiniz çok şey var. **Dondurma yiyebilirsin, hamburger yiyebilirsin, hepsini karıştırabilirsin.

Bu kavramı biraz daha somut hale getirmek için, basit durumda, 100 NFT basmak için 100 işlem gönderiyorsanız, 100 NFT basmak için bir işlem gönderebilirsiniz. Böyle bir maliyet, bir NFT basmanın maliyetiyle hemen hemen aynıdır. Ayrıca, bir bloktaki ilk işlemin multisig cüzdanınızdan bir Mario karakteri alması ve ikinci işlemin bir Mario istemesi ve ardından oyunu oynamanıza izin vermesi gibi heterojen işlem paketlemesi de yapabilirsiniz. Oyunu kazanır ve kupayı alırsanız, belki üçüncü bir ticaret kupayı arkadaşlarınızla paylaştığınız bir kupa dolabına koyar. **Harika olan şey, programlanabilir işlem bloklarının, programcıların, oyunun multisig cüzdanları veya Mario'nun nasıl saklandığını bilmesine veya ödül dolabınızı veya nasıl uygulandığını bilmesine gerek kalmayacak şekilde kod yazmasına izin vermesidir. . **

**Programlanabilir işlem blokları, girdi ve çıktı nesneleri içeren işlemlerden oluşur. **Giriş nesnesine ihtiyacınız varsa, nereden geldiğine bakmadan o nesneyi alıp, çıktısını ihtiyacı olan nesneye iletebilir ve nereye geçtiğini umursamazsınız. Diğer blok zincirlerinde bağlantı daha güçlüdür, bu nedenle oyunların multisig cüzdanları ve ödül dolaplarıyla entegre olması veya hepsinin ortak bir arayüz uygulaması ve daha güçlü bağlantıya sahip olması gerekir. **Sui, geçici olarak adlandırılan kombinasyonları çok daha kolay hale getirir. **Mesela borular eşleşirse tek işlemde yapabiliriz.

**S5、****Kullanıcılar için programlanabilir işlem bloklarının faydaları nelerdir? **

Kullanıcılar için programlanabilir işlem bloklarının avantajları arasında daha düşük gaz maliyetleri yer alır, çünkü tüm işlemleri ayrı işlemler yapmak yerine tek bir işlemde toplayabilirsiniz. Ek olarak, daha az onay gerektirir. İşlem onayı gerektiren bir sistem kullanıyorsanız, bunu yalnızca bir kez yapmanız yeterlidir ve ardından tek seferde hepsini yapar. Diğer bir faydası atomluluk'tur, eğer üç farklı şey yapmak istiyorsanız ve üçüncü işlemin yalnızca ilk iki işlem başarılı olursa başarılı olmasını istiyorsanız, bu işlemlerin bağımsız işlemler olması gerekiyorsa, o zaman bunu gerçekleştiremezsiniz. Ancak hepsini tek bir işlemde toplayabilirseniz, bunu kolayca başarabilirsiniz.

**S6, ****Sizin ve diğerlerinin Sui üzerinde geliştirme yapmaktan programcılar için harika bir deneyim olarak bahsettiğinizi duydum ve bu önemli. Sui Move'u kullanmaya başlayan deneyimli ve yeni Web3 programcıları için paylaşacağınız herhangi bir anekdotunuz var mı? **

Diğer Web3 programlama dillerinden gelen geliştiriciler için Move ve Sui Move'daki geliştirme deneyimleri gerçekten daha verimli ve daha güvenli. Az önce Bucket Protocol hakkında bir podcast'teydim ve Sui'de gerçekten harika bir DeFi projesi inşa ediyorlar. Sistem mimarisini gösterirken, farklı bileşenlerin birlikte nasıl çalıştığını açıklarlar. Bu projeyi Solidity'de yazmış olsalardı sekiz ay sürebileceğini, ancak Sui Move ile sadece iki ay sürdüğünü ve güvenliğine çok güvendiklerini söylediler. Dilin çalışma şekli, kafalarındaki bir proje portföyü fikrine çok yakın. Solidity dünyasında bağlantı daha az doğrudandır.

Bu sadece bir örnek, ancak insanların dilde daha hızlı geliştiklerini ve bitirdiklerinde daha özgüvenli hissettiklerini söyledikleri pek çok benzer vaka duyuyoruz. Bunu duymak beni mutlu ediyor. Ama bir bakıma bu şaşırtıcı değil, Solidity'ye baktık ve sorunları öğrendik. Bunu nasıl daha güvenli ve daha hızlı hale getireceğimize dair açık bir şekilde senaryolar tasarladık. Dili geliştirenlerin ne yapmaya çalıştıklarına ve zaten var olanlara hitap etmek yerine dili onların ihtiyaçlarını karşılayacak şekilde nasıl tasarlayacaklarına baktık. Dil, insanların sahip olduğu sorunlar için tasarlanmıştır, bu nedenle geçiş yaptıklarında dili gerçekten takdir ederler.

**İlk hamle avantajının önemli olduğunu söylüyorlar ama sanırım bu durumda geç hamle avantajı daha önemli. **

Bu doğru, bu kadar.

**S7、****Sui Move ve Sui'nin genel nesne yönelimli özelliklerinden bahsederken buna değindiniz. Ancak Sui Move'un tasarımı ile Sui'nin Web3 kitlesel benimseme, düşük gecikme süresi, düşük maliyet ve ölçeklenebilirlik elde etme yeteneği arasındaki bağlantıyı daha açık bir şekilde ifade edebilir misiniz? **

Sui'ye katkıda bulunmaktan çekindiğimiz şeylerden biri ve diğer platformların karşılaştığı sorun, sınırlı kapasiteniz varsa, Ethereum gibi saniyede 15 işlem (TPS) veya 100 veya 1.000 işlem gibi, eğer sabit bir sayı, daha sonra platform çok başarılı olduğunda kapasite üst sınırına ulaşacaktır. Bu noktada platformu kullanan herkesin deneyimi bozuluyor. Yalnızca 1.000 boş yer varsa, en önemli 1.000'i seçmelisiniz; bu, gaz ihalesi veya diğer yöntemlerle seçilebilir. Hepsi için, gaz fiyatları artacak, gecikme artacak veya her ikisi birden olacak. Yalnızca en yüksek ücretleri ödeyebilenler başarılı olacağından, diğerlerinin başka bir yere bakması veya daha uzun süre beklemesi gerekeceğinden, birçok kullanım durumu hariç tutuldu. Bu iyi bir durum değil.

**Sui, yatay ölçeklenebilirliği hedefler. **Belirli miktarda donanım tahsis edilirse, belirli miktarda verim elde edilebilir. Daha fazla verim gerekirse, doğrulayıcı üst sınır olmadan daha fazla donanım olanağı sunabilir. Her Web2 hizmeti bu şekilde çalışır. Demek istediğim, üzerinde çalışmanız gereken bazı mühendislik kısıtlamaları var, bu yapılması kesin veya kolay bir şey değil, ancak herkes ölçeklenebilir web hizmetleri tasarlarken yatay ölçeklenebilirlik elde etmek ister.

Sui'nin daha fazla müşterisi veya kullanıcısı varsa hedefimiz Sui'nin büyümeye devam etmesi ve her şeyin yolunda gitmesidir. Tabii ki, çok düşük gecikmeyi korurken. Verimi artırırken gecikmeyi feda etmek istemezsiniz.

Terazi sisteminde bu özellikler dikkate alınmaz. Sadece küçük ölçekli bir ödeme sistemidir, yüzlerce ödeme operatörü vardır ve günde on milyonlarca ödeme olabilir ama daha fazlası olamaz. Bu yüzden daha basit ve yeterli olan tek kutu mimarisini benimsedik. Ama Sui'de yatay ölçeklenebilirlik özelliği olmadığı için Libra sisteminin çalışmayacağını biliyoruz. Biz de sıfırdan bunu yapabilen bir sistemi nasıl tasarlarız diye düşündük. Nesne yönelimli veri modelinin devreye girdiği yer burasıdır. Yatay ölçeklenebilirliğe ulaşmayı çok zorlaştırdığı için eski hesap tabanlı veri modelini temelde bir kenara bıraktık. Bunun yerine, her şeyi nesneler halinde düzenlerseniz, genel durum, nesne kimliklerinden nesnelere kadar yalnızca büyük bir haritadır. Bu bir anahtar/değer deposudur ve anahtar/değer depolarının nasıl ölçeklendirileceğini biliyoruz, bu basit bir mühendislik problemidir.

O halde soru, anahtar/değer deposundan veri getirmeyi ve güncellemeyi barındıran bir işlem yapısını nasıl tasarlayacağımızdır. Bir anahtar/değer deposunu nasıl parçalara ayırırız? İşlemlerin nerede işlenmesi gerektiğine nasıl karar veririz? Temelde oradan geliyor. Bununla birlikte, bu şeyleri nasıl ölçeklendireceğimizi biliyoruz. Bunu blockchain özelliklerine, doğrulanabilir okumalara, Move ile çalışan vb. bir şeye nasıl dönüştürebiliriz? Ve sonra onları mümkün olduğunca sorunsuz bir şekilde nasıl bir araya getireceğiniz.

S8、** Daha üst düzeyde, merkezi olmayan teknolojinin potansiyelini Web2'ye şüpheyle yaklaşan geliştiricilerle nasıl tartışırsınız? **

**Blockchain ve kripto para birimlerinin temelde sürtünmeyi ortadan kaldıran bir teknoloji olduğunu düşünüyorum. **Finansal işlemler gerçekleştirmemizi, uygulama oluşturmamızı veya bilgi oluşturmamızı çok zorlaştıran engeller vardır çünkü bilgiler bu engelleri aşamaz veya bu engelleri aşıyorsa bazı üçüncü şahısların yardımını gerektirir ve Bunlar birinci Üçüncü taraf, yardım sağlayabilmek için bir ücret talep eder.

İnsanların kullanmayı sevdiği klasik bir örnek, bir ev satın almaktır. Bir alıcı ve bir satıcı var, ancak ödemeleri gerçekten yaptığınızda, orada oturup fonları emanet etmekten başka hiçbir şey yapmayan bir emanetçi olmalı çünkü alıcı ve satıcı birbirine tam olarak güvenmiyor. Bu hayatın bir gerçeği. Bununla ilgileneceğiz. Bununla birlikte, emanet aracısı, her iki tarafça da görülebilen veya bazı üçüncü taraflarca doğrulanan bir kod olabilirse, o zaman işi ücretsiz veya çok daha ucuza yapabilir. Blockchain'in amacı, gayrimenkuldeki emanet acentelerini ortadan kaldırmak değildir. Bu, kullanım durumlarından yalnızca biridir, ancak çoğu zaman böyledir.

**A uygulaması ile B uygulaması arasında artık birlikte çalışabilirlik engeli yoksa, ancak aynı temel platform üzerine kuruluysa, ister uygulama içi öğeler, ister veriler , promosyonlar arasında veya üçüncü sırada olsun, işlerin bir uygulamadan diğerine akışını sağlayabilirsiniz. -parti ürünleri her ikisinin üzerine inşa edilmiştir. **Ya da web sitelerinin birbirleriyle veri paylaştığı, ancak bunların yalnızca salt okunur meta veriler olduğu İnternet'i hayal edin. Ya bunlar para birimi olabilirse? Yoksa harcanabilir bir eşya olabilir mi? Veya sadakat programları ve kuponlar olabilir mi? Her şey yerleşik olarak bu işlevselliğe sahiptir. Çok soyut ama potansiyel burada yatıyor. Genellikle inşa eden bir kişi, bunları daha çekici bir şey inşa etmek için kullanabileceği yeni süper güçler olarak düşünecektir.

S9、** Son kullanıcılar için, teknik bilgiye sahip olmasalar bile, diğer seçenek opak olan büyük bir merkezi varlık olsa bile, kod güvenini düşündüklerinde tereddüt ediyor musunuz? **

Ben öyle düşünmüyorum. Çünkü her gün böyle şeyler yapıyoruz, değil mi? E-postama giriş yaptığımda, kodun e-postalarımdan birini sileceğinden veya bir e-posta gönderdiğimde aslında onu göndermeyeceğinden endişelenmiyorum. Bu olursa, muhtemelen e-posta kullanmayı bırakacağım veya başka bir sağlayıcı kullanacağım. Bence çok benzer, elbette herkes aslında bir şeyler okuyup nasıl çalıştığını kontrol edemez.

Ve e-postanın kodunu kontrol etmek istersem, yapamam çünkü kod orada değil. Dolayısıyla şeffaflık bunun önemli bir yönüdür. Herkes bunu yapamazken, bazıları bunu örnekleyebilir. Ve bunu, herhangi bir şeyin yeniden kullanımı ve değişmezlik ile birleştirin. Buradaki anahtar bu. E-postama giriş yaptığımda, kodun son yaptığımdan bu yana değişip değişmediğini bilmiyorum. Bu konuda şeffaflık yok. Bu bilgiyi bilseniz bile Web3'ten alabilirsiniz ve başka bir yerden alamazsınız.

**S10、****Sui Move'un gelecekteki gelişimi için beklentileriniz nelerdir? **

**Şu anda odaklandığımız özelliklerin çoğu, Sui Move paketlerinin ilk gruplarını yayınlayan ve ardından bu özellikleri nasıl geliştirmek istediklerine, hangilerinin geliştirilmesi kolay olduğuna ve hangilerinin geliştirilmesi gerektiğine bakan geliştiricilerle edindiğimiz deneyime dayanmaktadır. olanlar daha zordu. **Sui Move, ilk sürüm paketi için harika bir dil, ancak değiştireceğim tür için, bazı alanlar ekleyeceğim, bazı işlevler ekleyeceğim, bunu yapacağım tutarlı ama ilk paketin kullanılmasına aykırı olmayan bir şekilde Kullanıcıların güveneceği bir şekilde çalışmak, bu çok zorlu bir sorun haline gelir. Yaptığımız şeylerin çoğu buna bakmak ve programcılara, kullanıcıların orijinal koda olan güvenini korurken genişletme esnekliği sağlayan hangi dil düzeyinde özellikleri ekleyebileceğimizi belirlemektir.

**Bununla ilgili birçok özellik üzerinde çalışıyoruz, özellikle enum türleri. **Move'u ön uç koduyla bağlama deneyimini geliştirmek için de çok çalışıyoruz. Tipik bir Sui uygulamasının %5 Move kodu ve %95 ön uç kodu olduğu konusunda sık sık şaka yaparız. Bu yüzden bu %95'e çok odaklandık. Move hakkında konuşmak için çok zaman harcadık ama aynı zamanda diğer parçaları daha verimli hale getirmeye ve bağlantıları kolaylaştırmaya da çok odaklandık. Genel olarak, uygulamanın daha fazla güvenlik için nasıl daha fazla Move içermesi gerektiğine odaklandık. Aynı zamanda, kodun %95'ini hem Move programcıları hem de Move olmayan programcılar için anlaşılır hale nasıl getiririz?