Recap 8/10 Move AMA: Move Programming Language with Mysten Engineers

Jen:

Welcome everyone to our new AMA session about the Move programming language. We have here with us today our lovely Mysten engineers, Adam and Todd. Please introduce yourselves.

Adam:

My name is Adam Welc. I've been working on the Move team at Mysten Labs for roughly seven or eight months now. My main focus is developer experience and tooling.

Todd:

I'm Todd Nowacki. I've been on Move almost since its inception. It's been a small team the whole time and a lot of us have just kind of worked on whatever was the highest priority thing at the time. The biggest chunk of that was the compiler and the source language. Lately, at Mysten Labs, I've been working more on getting the language integrated into a more Sui-specific styling of Move.

. . .

Question #1: How is the Move team planning to onboard more devs and accelerate developer adoption of the Move language, especially considering the fact that it is a new language?

Adam:

We launched an initiative to carry out hackathons and workshops; some of them were held in Korea but there is a plan to do those in different parts of the world virtually and physically. We're really trying to boost awareness of the language and its features this way.

Another aspect of this is that the language was created at Meta but is now used throughout multiple different chains and Mysten Labs’ Sui chain is one of them. There's a bit of a community effort that will come not only from Mysten Labs but also hopefully from other companies to make it popular.

Todd:

The only thing I’ll add briefly to it is that the space is still rather young and small and these things take time to build. For the learning resources, we're trying to build awareness. If you have any feedback about theMove book or what Damir wrote for the repo, please let us know! Feedback like that is really helpful.

Jen:

In regards to what Adam was saying, we do have many more events planned to onboard developers across various skill sets. We're fully aware that a lot of people have a keen interest, and we've made it a point internally to look at virtual workshops plus in-person ones. We've received an overwhelming response to get more video-focused content and that is something that we're working through at this moment. We really appreciate that people have flagged this as something that they need and we're looking to respond in terms of how we can provide these resources.

. . .

Question #2: How can Move guarantee the security of assets in a way that other traditional blockchains simply can't?

Adam:

Move is an evolution of ideas that were present in the first generation of smart contract languages. So, it's similar to evolution in terms of thinking about safety and security changes that happened between when C and even C++ languages were developed and implemented and now when we have languages like Go or Rust.

In the old days, it was like “Oh, you have to be really careful if you program as threads to avoid races or deadlocks.” Rust took a completely different approach in that department; they basically said we will design a language so that if you write a program, our compiler accepts its program. A certain class of errors is just not going to be present in your program by definition or by design. For example, if you write a concurrent program in Rust and it compiles, you will not be able to deallocate memory and then reuse it incorrectly as you could have in C or C++.

So Move tried to go in the same direction as Rust did with those traditional languages, which is to try and prevent some of these things by design. For example, you will not have double-spending by design, and not every property can be verified by the compiler. You have an additional tool which is called the Prover which can be used in conjunction with additional specifications that you write into your code. But if you write those specifications, you'll be able to prove other things about what your program will or will not do at runtime, but you will know these things statically before your contract is even deployed.

Todd:

That was really good. The thing that I would like to add is there's a difficulty and a sort of nuance in deciding the things you don't want to allow. In the example that Adam gave about C++ versus Rust, their idea is that we want to stay kind of close to C++, but this creates a bunch of memory safety-related issues. This approach would have allowed memory unsafe code, so you would just have to wrap it up and then present it as being safe from the outside perspective. Move decided on a different approach that ensures memory safety similar to Rust.

. . .

Question #3: How do we ensure that there's safety and security built into our Move language?

Todd:

For Move, it's kind of like an all-or-nothing thing. You either make no changes to the blockchain, except for being charged gas and the failure or you have a successful change over storage. In Sui terms, it would be that you're taking some objects as input and you're either producing some new objects or transferring the objects or otherwise mutating them or you do nothing. I know that sounds very simple but this sort of all-or-nothing behavior rules out a lot of bugs because you don't have to worry about manually managing the memory of these changes.

The prover starts to come in when you want to define broader logical properties about your program like this function will never fail if the values on the inputs are greater than zero. That can be helpful to know as long as you pass in enough coins or tokens to the function it is impossible to fail or maybe, if you authenticate your keys correctly for this function, then you'll never fail.

Adam:

So to speak from the language perspective, sometimes locally, it's tough to tell if an object that you're seeing is shared or it's owned and I think prover can help make sure that if your function expects a shared object, it will be a shared object that is going to be passed on to it or if there is a non-shared object that is passed. Then you can define similar properties that Todd mentioned, but with respect to the properties of objects that can be checked non-locally as well.

Todd:

When I was talking earlier, we will continue to develop the language and learn new things and make changes as time goes on. One of the first things that we did in Move was set up the core Move account-based storage model but there are some downsides to this that became very different. Let's say that all of your coins are managed by this one coin module, you don't know if there is any module above it calling into this coin module. So you don’t know if someone can call this function and steal all of your coins. And when we tried a few different ways of solving this, nothing was that great. But in the Sui object model, we actually force you into presenting all of the objects you're going to modify at the time of execution. So when you begin execution, you can carve out whole regions of memory and say, I'm only going to write or modify within this region.

These are another set of guarantees, it just makes it a lot easier and a lot more understandable to understand what exactly Move functions are doing.

. . .

Question #4: Can you share with us some context and background around the VS Code plugin?

Adam:

We had a fairly rudimentary VS code plugin that has been developed at Meta by one of the original team members. When I came on board to Mysten, I kind of realized that it's not quite up to scratch, and if somebody is used to working with more traditional languages they're not going to be super happy with the developer experience. So initially, we just embarked on the task of supplying the VS code plugin with some of the features that you would want and expect from a more modern IDE. So things like going to a type definition, finding all the references typed on hover, and passing compiler diagnostics back to the editors.

. . .

Question #5: What is the impact that VS code plugin will have on the coding experience and developer teams?

Adam:

I got some reports that people actually started using the new features, which is nice. There was a workshop in Korea where Damir, our developer advocate and part of the Move core team was there in person running the workshop and working with people, and he kind of passed back the more informal feedback on this, which was that people actually use it and they liked it.

Todd:

I think that's probably going to be a different tool. I could imagine different sets of tools down the road that would make it easier to understand. Maybe how specifications are applied, what sort of coverage you're getting by certain things, or some other way of making the coding experience feel different than the developer experience. It's more like ‘‘I'm writing this function, what's the signature of this other function again, or do I want to see the code over here?’’ I guess the definition is probably the most helpful for non-developers if you're not used to a given code base. The code definition is amazing.

At the end of the day, if you're thinking about others, making their life easier or other sorts of non-technical people looking at Move code, you're probably going to want a different set of tools to help them.

. . .

Question #6: What are some external contributions that people might want to look at?

Adam:

I can speak to those that have already contributed and who are part of the VS code plugin extension already. So, if you go and look for issues with the Move analyzer tag in the Move repository, you will be able to see things that we plan to do and that we will do either ourselves or with the help of the community in more detail.

Remember that the VS code plugin extension happened recently – people only started picking up on what has been added there, which is the support for these additional features, that were allowed by a tighter compiler integration, which builds intermediate representation that lets you kind of do smarter things at the editor level.

This allowed some additional things to happen and one of those external contributions was to provide an outline view of the file that you were editing. If you're familiar with the VS code editor in general, it's on the left hand side there is a window that if you open it to this outline, it should show functions, type definitions, and the main outline of the source code that’s defined in the file. This has been added by one of the external contributors.

. . .

Question #7: What are the plans for Move’s ability to write generic code?

Jen:

For example, I recently had a use case to compare two things that are generic type T, which I think you can't do trait bounds, abilities, and also passing functions around as arguments to other functions.

Todd:

Yeah, traits, as you might expect them are function pointers that are just never coming to Move. You're probably thinking, I use higher order programming all the time, and Rust or JavaScript or pretty much any other programming language you use, why not Move? Well, it prevents a bunch of problems, and at the end of the day, Move is not a general-purpose programming language. We're trying to build safe things that we can prove to be safe and once you have dynamic dispatch, a lot of that goes out the window.

There are a lot of different ways to reuse code that I think we're kind of used to as developers, just like reaching for that trait interface pattern, and we're trying to do things a little bit differently here so we can have a higher level of assurance and language.

. . .

Question #8: Is Move EVM compatible or is it going to be compatible?

Adam:

The short answer is no, and yes. There has been an effort trying to have a cross-language solution or be able to compile or transpile Move into EVM bytecode at Meta. This was not picked up as far as I understand by any other chain that uses the language like 0x, Aptos, or Sui. I don't think there's any plan for any of these chains using Move to make it EVM compatible. The reason I think that it might have been attempted at meta was that you want to reuse the expertise that you've built in writing the language and developing code in the language and try to apply it to a wider space, particularly the original product that meta was developing in that space due to regulatory concerns; it kind of never worked out.

I think this was more about what we can do with the Move language to make it more palatable for a wider audience. The difference in the execution model and the guarantees that are offered by the EVM side of things are significant enough that I am not sure if this is ever going to work 100%. I actually also don't know if it's still being developed but at least for Mysten labs, and the Sui blockchain there is no plan to make it EVM compatible.

. . .

Question #9: Does moving to another language miss the point of resources and assets, for example, fungible versus non-fungible tokens is essentially what first-class quote unquote means in smart contracts?

Todd:

I don't quite understand the question. I'm not really sure about a few things like resources, assets and tokens are first-class baked things on Move. It's more than just the word asset, we have objects that are pretty much NFTs, even your coins are NFTs if you actually care about the idea of that coin; the fungibility aspect of it is a human concept when I care about something being fungible or not fungible this is a human level of discerning ability here. Like If I have a $1 bill in my wallet and you have a $1 bill in your wallet, you're willing to trade them because we don't care about it but if someone autographed my $1 bill, that might be important to me but not important to you. It’s Non-Fungible for me, but it's still fungible for you.

Adam:

When people use bank notes, the note is an example of a fungible token, but in fact, they are non-fungible because every one of them has a serial number so we just choose to ignore and exchange one for the other, but it's the same exact concept in Sui every coin object will have its unique ID but if you ignore them, then you basically have a fungible asset.