Recap 7/14 Sui AMA: Move Programming Language with Mysten Dev Team

Jen:

Welcome everyone, I'm really excited for today’s AMA! I'm pleased to present our lovely Mysten Move programming team.

Adam:

Hey, I'm the junior member of the team. In January, I joined the company at Mysten Labs.

I’ve had a fair amount of experience implementing and optimizing programming languages in general. I did a pretty reasonable job in enhancing the VS Code plugin that we have for Move and now it has a lot more features that make this a bit more convenient programming tool for our lovely devs.

Damir:

I'm Damir, the author of the Move Book and as of today, also the author of the Move Syntax package. I got into Move kind of against my will because my CTO said that this will be the language we’ll use. So I learned it, and then, of course, I fell in love. That was three years ago in 2019 and I'm still here.

Emma:

My name is Emma. The first time I started working on Move was when I was interning at the Move team and Facebook back in 2019. I've been working on Move full time since then. I also specified and verified a lot of the Move code in the Diem framework. Right now, I'm continuing this work on adapting Move to improve Move on Sui. What I like the most about the Move programming language is how we enforce safety at the bytecode level instead of the source code level. I think that really helps add another layer of protection.

Todd:

Hi, I'm Todd, I've been on Move since 2018. I was the third or fourth person on the project. I've been doing integration work at Mysten recently. In terms of fun facts, Move was originally an object-oriented language with classes, but we got rid of those modules. It's always amusing to me that we're back to objects. However, our objects now are very different from the first version of Move.

Sam:

I'm Sam. I'm the creator of Move and have been working on the language since the spring of 2018. I worked on a variety of areas in Move such as leading design and implementation formalization, reading research papers about the prover and analysis, and looking at making the language cross-platform. My fun fact is that the original name of the prototype was Tulip, but this name was very wisely rejected by the Diem leadership.

. . .

Question #1: How does the Move language differ from other programming languages and what are the characteristics that make it unique?

Emma:

Our language really was built with verifiability in mind. I think that really separates us from other languages, where normally the languages exist first and then later when it becomes more popular people start formally verifying them.

Adam:

I think what's unique about Move is that it brings interesting things (that have been done) from the world of smart contracts languages that are around other than Solidity. It also brings some very interesting concepts from more traditional programming languages. For example, the way the assets are encoded in Move is different than it has been traditionally done as far as I understand. Every time you create in Move, you essentially create an NFT with all the rich properties that you can modify. Move has been designed around this concept of being able to share code easily, which is why we integrated this concept of packages and modules. This allows you to write and publish source code somewhere that people kind of know what they're seeing on the chain, but then you don't have to copy and paste. There's this kind of notion of the language being both expressive enough, but also minimal enough that it helps with finding bugs and writing tools.

Damir:

Expressivity is one of the greatest features and what's really outstanding about the language. It is crazy that you don't need to write much code, you just go straight into the business logic of the application of your module and you get everything.

. . .

Question #2: Why can’t you use Rust instead of coming up with a new programming language? And why can’t the industry just settle on standards for the greater good?

Sam:

The short answer to this question is that we tried. It would be great if we could use Rust as a great tooling and ecosystem with great developers. However, Rust is a source language, and in these blockchain platforms, what runs on the blockchain isn't source code, it's byte code.

• You can't have the Rust compiler run whenever you try to publish your code on chain. It's a big and expensive piece of software, and it's going to take a long time to run.
• You can't just publish machine code directly on the blockchain because some attacker might directly publish machine code, and that does not have the guarantees source languages provide and can do malicious things to your code.

We're very much inspired by Rust. Initially, we had the idea to use Rust, but then we realized we can't do this because of this constraint about the executable format. Beyond that, there's a variety of other things to which languages are inherently somewhat application specific. Otherwise, we'll just have one programming language that does everything. Move is to take a lot of the good ideas, and put our own smart contract spin on it.

To answer the second part of the question, we've designed Move so that it does not overfit any sort of blockchain implementation details. It doesn't know about things like accounts or transactions or cryptography grants. There are five different blockchains that are using Move and they all look quite different under the hood in terms of how they set up their transactions, how they do storage, how they do account structure, and how the consensus works.

Adam:

I think two things that convinced me that you can't really use traditional programming languages easily on the blockchain are:

• They haven’t been implemented with gas metering in mind.
• If you need to be able to deterministically replay computations, those languages won't work.

. . .

Question #3: Why is Move based on Rust?

Sam:

I think based on is a little bit too strong, but I think it's certainly strongly influenced by Rust, particularly by the ownership type system called borrow checker. I think any language going forward, whether it's inside the smart contract space or outside, should take a careful look at the borrow checker. In terms of syntax, our syntax is similar to Rust in many cases.

We care a lot about making it easy to learn as a Rust programmer, an inexperienced programmer, or someone coming from an existing smart contract background. We make it at least similar syntax-wise and in many aspects design-wise to Rust.

. . .

Question #4: There’s a general assumption that Move is less flexible than Solidity so why was Move chosen for our blockchain?

Damir:

Move aims to be statically verifiable and prevent all possible errors during the compilation stage so you can't rely on something that will be published on the blockchain later. By design, it’s impossible to flex because everything happens in the compilation stage. If you compile your code and push it, it will also run like bytecode verification. So when you publish, it's guaranteed to be secure. It’s less flexible in that sense, but more secure in response.

Sam:

I might be nitpicking on terminology here, but I think expressiveness is good. I don't think flexibility in a language is necessarily good. Flexibility can open up the door for vulnerabilities and attacks. So in Move, what we aim to do is be just as expressive as the EVM Solidity, and in fact more expressive, but may be less flexible in the sense that there's one way to do something instead of multiple ways. The one way to do it is safe instead of potentially scary and vulnerability introducing.

. . .

Question #5: How can projects that are based on Move cooperate with those that were built on EVM?

Emma:

Right now we're actually working with Celo which is an EVM-based blockchain to bring Move into their channel. The goal of this project is to have both Move and EVM supported on the Celo blockchain so you can write either Solidity or Move contracts or both, and publish them on Celo to interact. We also hope to incorporate some sort of communication between the two VMs. Stay tuned for that project!

I want to mention the Move to EVM compiler. You can provide Move code, and it compiles to EVM bytecode for you. You can even use the same set of test cases for both contracts in both languages. I feel like that product has a pretty big potential for helping with that communication between Move and EVM.

. . .

Question #6: What are the advantages and disadvantages of Sui and Aptos?

Sam:

Move is this embedded language where there's the core language that's very unopinionated. Usually, creating an account is straightforward. For example, if they want to mass drop NFTs to users as a growth hack, you can have an address without having an account so the NFT can be dropped to you. You can see that it’s yours on Explorer and play the game. Later, you can create an account when it's convenient for you.

That sort of thing isn't possible on the Diem-style integration of Move because of this requirement that you need to explicitly create an account first and then opt-in to receive a particular asset type. On Sui, we started to organize things around objects that have globally unique IDs, and this means that you can just transfer an object to anyone. We think that sort of thing is permissionless, sort of like extendable games where a lot of folks can collaborate to build the same thing. We go deep on both the technical language aspects of why we did this and the sort of use cases of enabling and why they're difficult or impossible to do in the old Diem-style of Move.

Jen:

For us, as a team, we are focusing on our efforts, and there is mutual respect between the companies. So, to the community, always treat our competitors with respect because everyone you'll notice from within the organization is trying their hardest and they really do believe in what they're building.

. . .

Question #7: What are your thoughts on closed-source smart contracts? And will Sui allow the published packages to be closed source?

Adam:

I think that closed source kind of goes against the spirit of what the blockchain platform is trying to achieve. And the same with Sui, as a user of a blockchain, would you really like to send money to be handled by a smart contract that you don't know what it does?

We want to encourage code sharing, and there are these projects that are happening within the community that will kind of make this easier. The notion of the close source may have a double meaning. Whatever you publish on the chain that supports the Move language, the bytecode, it's not a closed source because you can always inspect the bytecode.

. . .

Question #8: Are there any specific core changes that need to be addressed in the future for the Move VM?

Todd:

We have a new storage layer that introduces a new way of interacting with storage in Move. The Move VM has the ability to add new native functionality without adding new bytecode operations. We have been successfully running our own set of verification checks on top of the normal verification checks that the VM does for Move bytecode.

. . .

Question #9: If I have zero experience in programming, can Move actually be the first language that I learn?

Damir:

You can start coding with Move; you take any of the existing books to learn Move and publish a smart contract. But the limitation of that will be that you will only be able to interact with your smart contract or like a module on the network. It's nice to see someone working on it, but you will always need a second language that will be like a more general purpose language to really ship something that is complicated enough to get people's attention, for example building something (a dApp) on the website.

. . .

Question #10: Are there any tips for getting started, or becoming better, for someone who is new to programming languages?

Damir:

We will soon start showing how to build the apps, how to work with small knowledge of JavaScript, how to do automated publishers, or how to call Move contracts from outside the blockchain like JavaScript. I mean, we're slowly going in this direction.

Small note, I saw some people in Discord mentioning that the best way to start is to read the Move book.It's a step-by-step guide, with lots of words, but for some people, it works. Then you can jump into the official Move documentation, and also to Sui docs:

https://docs.sui.io/

https://examples.sui.io/

These docs kind of show how to get started with Move on Sui, and I think it’s pretty prolific. There are lots of explanations so it's a nice way to start.

. . .

Question #11: How should we understand Move assets?

Emma:

In Sui, 10 Sui tokens basically mean that you have a Sui coin token that has the value in your address and that's it. On Ethereum, let's say you have 10 tokens of some sort. In the smart contract, there is an entry for you that has a value of 10 tokens – which is less intuitive than our model, and you also don't truly own those 10 tokens; it is just like the value in someone else's contract.

In Solidity if you want ERC-20 token transfer, they cannot happen at the same time. It has to be executed sequentially. Therefore, I think Move will have the potential for more because of our model.

. . .

Question #12: What are your thoughts on modules in Sui being mutable after being published?

Todd:

You know, we've been thinking about this a bit, and it's a tricky problem. There's this double-edged sword where you can fix bugs, but you can also introduce them. We're still kind of thinking about it and the thing I'll say is that there are a lot of different layers. We want some versioning of modules to be in the core language because it's something that's going to appear on every blockchain instantiation of Move. At the end of the day, you're always going to have some version of a new version number, which means more or less, creating a new package.

. . .

Question #13: Why didn't Meta license Move?

Sam:

I think many people who love doing this sort of thing, they'll pick it up as a hobby and do it in their spare time until it will eventually becomes a thing. This is something that I really love about programming languages. They're fundamentally free and open, and that's what gives them more value.

. . .

Question #15: What are the current research efforts on verification with Move? And what are some of the things that you are working on right now in regard to verification?

Emma:

The reason why we have to adapt new primaries is because the prover was really built for Diem, and we have over-fitted to the Diem global storage model, which is different from Sui. Our Move proof command should work for simple post conditions and abort conditions, but it won't allow you to specify anything about object storage. That will be coming hopefully soon.

. . .

Question #16: Will there be videos on how to code on Move?

Jen:

We're going to create different modules: beginner, advanced, and intermediate tracks, with visual videos giving different types of content to help with onboarding.

Jen:

Any final words before we close this grand AMA session?

Damir:

Let's just leave a wish to see more Move developers, more Move developers!

Damir:

Huge thanks to everyone who's doing content about Move; we see a lot of resources, and we're super grateful for that because it's really hard to cover all the topics. I mean, we don’t always know how Move behaves, we discover new patterns, we discover new things all the time, and we just can't cover everything. Move is something that is fun to explore.