Recap 7/28 Sui AMA: Move Programming Language

Koh:

Welcome everyone to today’s AMA session, my name is Koh and in today’s session, we will talk about the Move programming language. Now, I’ll let the team share their interest. Let’s start with you Damir.

Damir:

I'm fighting to make my official title in the company to be the Move Guy but for now, I'm just the Move software engineer.

Todd:

I have been working on Move since 2018. I wrote the source language and some other compiler stuff. I've dabbled in other various things on Move, whether it be the VM or tooling. Now, I’m more focused on the way we've been integrating Move on Sui.

Adam:

I'm also on the Move team and my current focus is on developer experience and tooling. My recent work was on improving the status of our Visual Studio Code plugin for Move and it’s now much better than it was a couple of months ago.

Emma:

I've been working full-time on the Move team since 2020. Most of my contributions are to the Move prover, I also wrote a lot of formal specs for the Diem framework. Right now, I’m contributing to Move and writing a lot of code for our Sui Core Framework.

. . .

Question #1: Is the language object-oriented or what architectural approach is recommended to use when creating an application?

Todd:

I'll say that object-oriented is a loaded term. There are objects in the

Move core language; we’ve added things that we call objects on the Sui side of things. I think they behave like objects in some sense but you're not going to find the object-oriented programming style that you might expect if you're coming from Java or other object-oriented languages. You might expect interfaces or inheritance or dynamic dispatch, or virtual functions, all that sort of stuff, but it's not there.

The thing that we do have for objects is more from a storage model perspective. We have individual kinds of packets of data that are of a given type with an ID and we call those objects.

. . .

Question #2: Do you support translators that anyone outside of Move can use, and how are you planning to apply this?

Adam:

Move is a different language and it's not just about syntax. If you look at different programming languages, there are common features like loops, variables, functions, etc but if you look a little bit deeper into the space of languages that target blockchains, the differences are that they can run quite deep. That's the same situation with Move and other languages that you might want to use to program smart contracts for different blockchains. Most security properties, for example, it's an inability for analysis, the way it manages memory, and the way it manages storage. All these things are quite different from most other languages.

So I would say, at the very least, it’s nontrivial and in some cases, probably also impossible to just write a transpiler or a translator that would take code written in one language that targets a blockchain and magically spits out Move code that would just work.

. . .

Question #3: How does Move help improve smart contracts for Sui? And, how do you achieve that security, especially with scale?

Emma

Compared to other languages, Move was designed for the blockchain use case. It borrows a lot of security features from languages like Rust and it also is designed to be more formally verifiable from the ground up. We plan to specify the core Move codes that handle like, how do we distribute rewards. How do we transfer money? This will also help with security.

Adam:

The languages to write smart contracts were available at the time when Move language was created, just didn't have built-in safety properties. Everything has to happen by sort of explicit programming intervention. With Move, many things are enforced by the compiler, or by the prover as Emma already mentioned. However, even without the prover, the properties that you would like to preserve like no double spending, they're just built into the language. That's kind of the main advantage and difference between some of these traditional older blockchain languages like Solidity.

. . .

Question #4: What advantages does Move have over specific other languages?

Damir:

Move is an asset-centric language, meaning it provides you a way to define an asset type, something valuable on the network, and that is the main difference that gives Move expressivity. In most other languages, you have to invent the meaning of an asset, instead of defining and saying this is an asset that can take multiple steps. Move allows you to achieve it in a really short, simple, and straightforward way.

Todd:

So besides the assets, the question here is, why do I need a blockchain-specific language? And why can't I just use Go or Rust or WebAssembly or something else? I think assets are a part of that answer but we also have:

• Determinism: If you just throw Rust or Go at this thing, the languages are not deterministic and you'll have to do a lot of work to try to make that true. You’ll end up building a sub-language inside of this thing and you're probably not going to be using any of the libraries you'd like to use in the past. You’re losing utility by building an entirely different environment of a language within the same language.
• Metering: You want to make sure that you're not using more resources for the computation of the network than you've paid for and that the network is determined and fair for you to use. Paying for them is one way but you need the ability to meter the execution and to be able to say, I've done X amount of computation, and you owe me this much in order to pay for it.

. . .

Question #5: What updates are you most excited about in the new Move version? And how can developers take advantage of that?

Todd:

The big one of the Sui optics is parallelism. Normally in a blockchain environment, all transactions are sort of ordered, even ones that aren't related. For example, Alice is sending a coin to Bob and says I am also sending some coins to Adam and Emma, those transactions aren't related but in a normal blockchain, you have to wait for all of them to go through consensus in the same order. It’s just kind of silly, so in Sui, we have this object model that lets us know if those operations are related or not so we can run them in parallel and in the original form of Move.

Damir:

To add on top of that, we also have different ownership models and different storage models that will also provide additional security over ownership. So, if you own something, no one can take it from you. However, in solidity and possibly in core Move, if there is a bug this module cannot access your object.

Koh:

Thank you. There were a lot of follow-up questions on parallelism, especially with the shared object versus a single object. Does anyone want to provide input on that in particular?

Todd:

Okay, what happens if I want a lot of people to access the same object? We have two methodologies for doing that on Sui:

• You can have a shared object that anyone can access; it might be a transaction or some modification on the object. In this case, we're gonna have to go through consensus, like you're used to. However, we only need the consensus over that shared object o other objects can still be running in parallel. Moreover, we can run in parallel with other shared objects.
• You can have a situation like, I'm done with this object, all the data is immutable, I'm not changing it. I just want other people to pull data from it and their own transactions immutably. So you can make this read-only object and call that freezing to an Immutable object.

. . .

Question #6: What are the courses available for the Move language?

Damir:

If you want to learn Move, I'd say just go straight into Sui documentation. We have everything written down step by step. You can just try this code and deploy it on the network.

We also have a nice resource if you know a bit about coding. There are a set ofexamplesto help you get started. It covers most of the main features of the Move specifically but when you look at them, you kind of get the point because most of the examples are really sharp.

Adam:

Two pieces of clarification from my side: don't be scared about the dependencies. I think that the main problem with installing dependencies is on Windows, so the instructions are obviously there. This should be even simpler and all of this is available online for free, all the documentation is open, and we also welcome contributions. Visit theSui Developer Portal, find our documentation and start hacking.

. . .

Question #7: What is the long-term vision for Move? And where are we going moving forward?

Todd:

There are a lot of different things we could talk about, I will try to hit on a lot of them.

• We're looking at expanding the usability of the language and keeping our eye on the expressiveness of the language. We need better developer tooling, whether it be tools that you might expect like auto-formatting or the increasingly making it easier to write tests.
  
• There's a long stream of work to do on getting people to learn the language as we're talking. On the prover side of things, we still have to get the prover fully working and integrated into Sui to make it easier for people to write.
  
• There’s also the usability of the language. There are things that, again, we take for granted in other languages, whether it be nice little syntax tricks like index access into vectors using brackets and for loops in general.
  

Emma:

There are also things we want to improve upon Move on Sui, for example, improving the object model a little bit by introducing different types of ownership.

Right now, we are not able to pass a vector of objects into an entry function, and it's affecting our expressiveness a little bit. There are some codes that I'm not able to arrive at because of lack of that, so we're also working on improving those things.

Adam:

It’s all up to you where the language is going to go, meaning you developers, you the community, and we welcome feedback. In fact, we hope that our work in the future in addition to what we think is good for the language and good for the ecosystem, we hope to be driven by what the actual people that use the language feel is important for the language in the ecosystem.

Damir:

At this point, a lot of people ask us about the language and we don't know. We can't know at this point in time, because all of us have been involved with the language for a long time. We don't know the beginning or the path to the language. So, ideally, please submit some feedback. If you go through the tutorial and don't understand something, please send us a message so we know that this is not clear.

Koh:

That was all the questions we had but let's take a few minutes to get questions from the audience if there are any.

Community Member #1:

Hi everyone. I want to get a nice synthesized view of this idea of the theory. I obviously have ERC 20, and ERC 721, and I kind of like the idea that in Sui that's maybe not necessary, or it seems like theorems are very interfaced-centric. Whereas, in Move, it's type centric almost based on the idea of generics, and statically verifiable. If you could just talk about that and how you envision token standards evolving?

Damir:

Okay. So interfaces exist in the Solidity world, just so people know that this code that kind of builds a token is actually a token. Since having the coin type basically says that this is ERC 20 or this is a Sui coin and so we have this alignment between all coins and they all behave the same way. Regarding ERC 721, or other NFT standards, we also don't need them because every object by default is what people usually call NFT, even the coin itself, just one coin with some value is an NFT in some way. We don't say that this coin is the only coin that can exist because we assume that there will be projects that will create their own coins. It will be a different type, it will behave differently, and it might have some authorities that manage this coin or just some ways to work with this coin like imagining the coin that can only be displayed twice in-house, it is implementable.

Todd:

One of the great things about coins is that generally, you want all your coins to behave the same way. The whole point of the standard is that you're on the solidity side of things so you're like, I want to be able to do these operations of recording and you probably want them to work the natural way of like splitting and joining and all this sort of thing. So you don't have to go out of your way to write your own module, you just write a struct.

Community Member #2:

I've got a quick question about publishing modules that contract when it comes to updating or changing them. For example, using proxy contracts in solidity, is that the case? Or is it a matter of just sort of touching on the wrapping capabilities on how you build it out? Maybe some thoughts around that?

Todd:

Yeah, we've been talking about this a lot recently. I'll say that you can, depending on the object, you could do a proxy setup. All I'm saying is that you can write a new module that uses existing assets. Depending on the things exposed in the existing module, you can essentially write version 2 of it or at least have some wrapping behavior. We are looking into the problem of trying to fully replace a package with a new version of the code.

There are some security concerns that come with this like, how do you make sure that someone's not doing something nefarious or evil and trying to steal existing assets? How do you make sure that they aren't introducing new bugs or that there's a whole set of problems there?

We're just trying to work out all the details and trying to answer some of these questions.