Interview with the Father of Move Language: Move Has the Advantage of Being Late, and Blockchain Is Fundamentally a Friction-Reducing Technology
TechFlow Selected TechFlow Selected
Interview with the Father of Move Language: Move Has the Advantage of Being Late, and Blockchain Is Fundamentally a Friction-Reducing Technology
For developers coming from other Web3 programming languages, their development experience on Move and Sui Move is indeed more efficient and secure.
Navigating Web3 tides with focused insightsRecently, we spoke with Sam Blackshear, Chief Technology Officer at Mysten Labs and creator of the Move programming language, about why he developed Sui Move—a new smart contract programming language—what capabilities enable Sui to scale, and how decentralized technology benefits builders.
Below is the full interview:
01. First, could you briefly explain what a programming language is, what qualities developers care most about when choosing one, and what motivated you to create your own?
A programming language is simply a tool for interacting with computers in a friendly, safe, efficient, and precise way—which is especially important because we can't use natural language to communicate with computers. The very purpose of natural language is richness and expressiveness. Small changes in tone or word choice can completely alter the meaning of a sentence or paragraph.
In contrast, the most critical aspect of a programming language is having precisely defined semantics. When you write a program, you know exactly what it will do. If you make a small change, you understand exactly how that will affect its behavior. This consistency must hold across multiple layers: code written in a source language has a certain meaning, and as it’s transformed into other representations, that meaning must remain unchanged all the way down to the machine level.
I believe, unlike natural languages, programming languages are inherently domain-specific or task-specific. Otherwise, one universal language would suffice for everything. But since there are many different languages, it's because no single language excels in every area. Each aims to target specific problem domains and focuses on solving those problems effectively. For example, Rust—the language we use to build the Sui blockchain and much of our other systems work at Mysten—is designed for writing fast, high-performance code while ensuring safety. It gives you access to low-level details like memory, thread structures, or concurrency, but without the pitfalls common in earlier languages like C or C++.
The story behind Move is quite similar. When I created it, my goal wasn’t just to invent a new language. You mentioned what developers look for in a language—they ask, “Is this language suitable for what I want to accomplish?” But arguably more important questions include: “Does it have a large community? Are there abundant libraries? Is it widely used by developers? Are there strong educational resources?” These factors are crucial. The barrier to creating a new language is extremely high—even if the language itself is technically superior, without these elements, its advantages become meaningless. Building a large, vibrant ecosystem from scratch is incredibly difficult.
02. Could you share more about the development of Move?
Move originated from Facebook’s Libra project. My task wasn’t to create a new language per se, but rather: “Libra needs smart contracts—figure out what we should do.” So I explored various options. Could we use Solidity within an EVM? Should we use a general-purpose runtime like WASM or JVM for Libra? Or should we build something entirely new?
We ultimately decided to build our own solution based on research into existing smart contract platforms—understanding what developers were trying to achieve, where current languages helped them, and where they fell short. My conclusion was that, in many cases, existing smart contract languages failed them significantly.
This is evident from Solidity’s poor security track record, but more fundamentally, smart contracts aren’t typical programs. Solidity wasn’t built for what people now expect it to do. I’m not criticizing it—after all, it was the first smart contract language and couldn’t anticipate future use cases. Once you observe how people actually use it, it becomes clear that a different set of abstractions and programming tools is needed—tools that Solidity doesn’t provide.
Smart contracts tend to be relatively simple and perform two core functions. They define types of assets—including rules around when assets can be transferred, what you can do with them, who can read them, and who can modify them. And they enforce access control policies—determining who owns an asset, who is allowed to use it, and who can operate on it. Everything revolves around assets, and ideally, these digital assets should behave like physical ones. If I hand something to you, you should own it, and I should no longer possess it.
Smart contracts involve concepts like ownership and transfer of ownership, yet in computing, everything is just bits and bytes—freely copyable. These real-world notions don’t exist natively in software. Therefore, you need a language that provides strong abstractions for ownership and uniqueness—like in the physical world—but without forcing programmers to reinvent them each time. You want fundamental safety guarantees built-in.
That’s exactly what Move does—and why we ended up building this new language. These features are foundational to smart contract programming. They’re hard to replicate reliably in other languages, including existing smart contract languages. We wanted to design an entire language centered around providing these core capabilities so developers could write secure, efficient code without constantly reinventing the wheel.
03. Sui uses a variant of Move called Sui Move. What prompted these changes? What aspects of Sui Move are particularly well-suited for building products in Web3?
Several factors drove these changes. One key point was that the original Libra project aimed to build a compliant payment network. As such, we designed Move (https://docs.sui.io/learn/sui-move-diffs) as a general-purpose language, but made deliberate trade-offs due to Libra’s compliance goals. For instance, Libra didn’t want users freely sending certain assets anywhere. Instead, account creation required explicit setup with rules—for example, requiring KYC verification, charging fees, or limiting creators to a small authorized group. Since Libra focused on regulated payments and compliant smart contracts, such restrictions made sense. However, in broader Web3 contexts, the opposite is true. You don’t want compliance enforced at the base layer—that defeats the purpose of programmable, permissionless innovation. You want maximum freedom—to send assets to any address. You also don’t want mandatory account creation, as that blocks many potential use cases. This was a major driver of divergence.
Another factor was that although Move emphasized assets, in Libra we didn’t fully integrate asset-centric thinking into transactions themselves. At the transaction level, you still worked with inputs like numbers and booleans—not assets directly. In Move, you’d use those values to fetch assets from accounts and perform operations. As a result, much of the code became tedious bookkeeping: fetching one item, then another, then another—“Okay, now I have all the assets I need in my local workspace, so I can finally start doing meaningful work.” Then at the end, you’d repackage and return them: “Put this back here, put that back there, reorganize things.”
In Sui, we asked: if every program starts and ends this way, can we abstract it away? The logic handling transactions can automate this process—so from the developer’s perspective, required assets are ready upon entry, allowing them to jump straight into interesting logic. This is the object-centric data model present in Sui. In original Move, we had an account-based model—assets stored under accounts, explicitly fetched by developers. In Sui, the runtime automatically retrieves assets before entering the Move portion of a transaction. This simplifies life for developers by eliminating boilerplate setup and teardown. It’s also the secret weapon enabling us to determine whether transactions can run in parallel without execution, allowing horizontal scaling and greater efficiency in other areas.
We’ve also done other innovative work, such as programmable transaction blocks leveraging the object-based data model. It’s a technical topic, and I’d love to dive deeper. But these two factors were the primary drivers behind Sui Move’s divergence from original Move.
04. Could you elaborate further on programmable transaction blocks and their functionality?
I like to use an analogy: other blockchains resemble a food court in a shopping mall. You want ice cream, so you go to the ice cream stand and pay with your credit card. Then decide you also want a burger—you go to the burger stall and pay again. I'm not greedy, but if I wanted eight items, I'd need eight separate transactions. Sui is more like a buffet—each transaction isn’t limited to one action. Once you've paid the entry fee, you can do many things without additional cost. You can eat ice cream, eat a burger, mix them together.
To make this concrete: in a simple case, instead of submitting 100 transactions to mint 100 NFTs, you can submit one transaction that mints all 100—with nearly the same cost as minting a single NFT. You can also bundle heterogeneous actions—for example, the first transaction in a block withdraws a Mario character from your multisig wallet, the second initiates a game using Mario, and if you win, the third deposits the trophy into a shared cabinet with friends. The cool part is that programmable transaction blocks let developers write code so the game doesn’t need to know about your multisig wallet or how Mario is stored, nor about your trophy cabinet or its implementation.
Programmable transaction blocks consist of transactions with input and output objects. If you need an input object, you obtain it without caring where it came from; you pass the output to whatever needs it, without knowing where it goes. On other blockchains, coupling is tighter—the game must integrate directly with both the multisig wallet and trophy cabinet, or they must implement shared interfaces with stronger dependencies. Sui makes temporary composition much easier. If the pipes fit, we can do it all in one transaction.
05. What benefits do programmable transaction blocks offer end users?
For users, benefits include lower gas fees, since multiple operations can be packed into a single transaction instead of many individual ones. Additionally, fewer approvals are required. If your system requires transaction confirmation, you approve once and everything executes atomically. Another benefit is atomicity: if you want three actions to succeed only if the previous two do, you cannot guarantee this across independent transactions. But packing them into one transaction makes this straightforward.
06. I’ve heard you and others say that developing on Sui offers a great experience for programmers—and that matters. Do you have any anecdotes to share about experienced and new Web3 developers getting started with Sui Move?
For developers coming from other Web3 languages, the experience with Move and Sui Move is significantly more efficient and safer. I recently joined a podcast about Bucket Protocol, a team building a cool DeFi project on Sui. During their architecture walkthrough, they explained how components interact. They said that building it in Solidity might have taken eight months, but with Sui Move, it took only two—and they feel far more confident about its security. The language aligns closely with how they naturally conceptualize their system. In Solidity, that connection is less direct.
This is just one example—we hear similar stories often: people report faster development cycles and greater confidence upon completion. That makes me happy. But in a way, it’s not surprising. We studied Solidity and understood its pain points. We deliberately designed Move to be safer and faster. We looked at what developers were trying to achieve and designed a language tailored to those needs—not constrained by legacy assumptions. The language solves actual problems people face, so when they switch, they truly appreciate it.
People talk about first-mover advantage, but in this case, I think second-mover advantage is more important.
Exactly.
07. You’ve touched on Sui Move’s and Sui’s overall object-oriented nature. Can you more explicitly connect how Sui Move’s design enables Sui to achieve mass adoption in Web3 through low latency, low cost, and scalability?
One thing we’re acutely aware of—and a challenge faced by other platforms—is that if your capacity is capped, whether Ethereum’s ~15 TPS or even 100 or 1,000 TPS, once the platform becomes too successful, it hits a ceiling. User experience degrades for everyone. With only 1,000 slots available, someone must decide which transactions get priority—via gas bidding or other means. Gas prices rise, latency increases, or both. Many use cases get priced out, forced to wait or leave. That’s not ideal.
Sui aims for horizontal scalability. Given a certain amount of hardware, you get a proportional throughput. Need more? Validators add more hardware—there’s no upper limit. This mirrors how every Web2 service operates. Sure, engineering challenges exist—it’s not trivial—but horizontal scalability is the gold standard for scalable web services.
If Sui gains more users, our goal is for the network to grow seamlessly, maintaining smooth performance. Crucially, this should happen without sacrificing low latency. You shouldn’t have to trade speed for scale.
The Libra system didn’t consider these traits. It was envisioned as a small-scale payment network with hundreds of payment providers processing tens of millions of daily transactions—no more. So we used a monolithic architecture, simpler and sufficient. But we knew that wouldn’t work for Sui. Without horizontal scalability, the system would eventually bottleneck. So we asked: how can we design a system from scratch to achieve this? That led us to the object-centric data model. We abandoned the traditional account-based model because it makes horizontal scaling extremely difficult. Instead, organizing everything as objects turns global state into a massive mapping from object IDs to objects—a key-value store, which we know how to scale. That’s a solvable engineering problem.
Then the question became: how do we design transaction structures to align with reading and updating data from a key-value store? How do we shard it? Where should transactions be processed? That’s essentially where it comes from. We knew how to scale these components. Then came the challenge of transforming them into something with blockchain properties—verifiable reads, compatibility with Move, etc.—and integrating them as smoothly as possible.
08. At a higher level, how do you discuss the potential of decentralized technologies with skeptical Web2 developers?
I believe blockchain and cryptocurrency are fundamentally friction-reducing technologies. There are barriers that make financial transactions, app development, or information sharing difficult—because data can’t cross boundaries easily, or doing so requires third-party intermediaries who charge fees for their involvement.
A classic example people cite is home buying. There’s a buyer and a seller, but when it comes time to pay, an escrow agent is needed—someone who just sits there holding funds because the parties don’t fully trust each other. It’s a reality of life. But what if the escrow agent could be code visible to both sides—or verified by a neutral third party? Then the job could be done for free or at much lower cost. Blockchain isn’t about eliminating escrow agents in real estate—it’s just one use case among many where trust bottlenecks exist.
If interoperability barriers between App A and App B disappear—because they’re built on the same foundation—then value can flow freely between apps: in-game items, data, cross-promotions, or third-party services built atop both. Imagine the internet, where websites share data via cookies—but those cookies are just read-only metadata. What if cookies could be money? Spendable assets? Loyalty points or coupons? All with built-in functionality. It’s abstract, but that’s the potential. Builders often see these as new superpowers they can leverage to create more compelling experiences.
09. For end users—even non-technical ones—do you sense hesitation around trusting code, even when the alternative is opaque centralized entities?
Not really. Because we already do this every day, right? When I log into my email, I don’t worry that the code will delete a message or fail to send one. If it did, I’d stop using it or switch providers. I think it’s similar here—of course, not everyone can inspect code to verify how it works.
And you know, I can’t check email’s code even if I wanted to—it’s not accessible. So transparency matters. While not everyone checks, some people do spot-checks. Combined with repeated usage and immutability, that builds trust. Here’s the key: when I log into email, I don’t know if the code changed since last time. There’s no transparency. But in Web3, you *can* know—and that visibility simply isn’t available elsewhere.
10. What are your expectations for Sui Move’s future evolution?
Many of the features we're currently focusing on stem from our experience working with developers who released early batches of Sui Move packages—observing how they want to evolve them, which parts are easy to extend, and which are difficult. Sui Move is excellent for launching initial packages. But evolving them—changing types, adding fields, introducing functions—while maintaining coherence and preserving trust among users of the original package, has proven challenging. Much of our work involves studying this issue and identifying language-level features that grant developers flexibility to extend code while retaining user trust.
We’re exploring several related features, especially enum types. We’re also investing heavily in improving the experience of connecting Move with frontend code. We joke that a typical Sui app is 5% Move and 95% frontend. So while we spend a lot discussing Move, we equally focus on making the other 95% more efficient and integration easier. Overall, we aim to increase the proportion of applications written in Move for enhanced security, while also making that 95% accessible and understandable to both Move and non-Move developers alike.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Sui Network
