It’s no secret that I’ve been in a real groove with Rust and Rust-based domain specific languages lately. For ETH Denver this year, I had the pleasure of extensively using the Sway programming language to create a decentralized bounty board. Sway is a rust-based DSL for smart contracts using the Fuel Virtual Machine runtime. Despite some wide architectural differences between the EVM and FVM, such as having a UTXO based model, most of the expressions I find myself accustomed to were readily accessible in the standard library (like msg.sender, block.timestamp, msg.value, etc). Fortunately, I felt right at home for a lot of this hackathon while using Sway, despite it being new to me.

Sway smart contracts are typically laid out in four parts using Sway: a declaration of the contract, the ABI which contains the function declarations (like traits in Rust) and storage access patterns, optionally a storage block for variables in storage, and the ABI implementation for Contract. I love this program structure because it feels clear to me where everything fits together, even if we have a few more declarations via macros. User defined types, events, errors, and the ABI can all be placed in separate library files and imported with dep and use statements to reduce clutter inside of the main program.

From the standpoint of idiomatic Rust, there are a couple syntactic differences to keep in mind when using collections in Sway. To retrieve a value at some arbitrary position in a vector, we call .get(…) on the type instead of using brackets and providing the element’s index. Enums will always have a type specified by default, if none, a unit struct. Lastly, HashMaps only exist inside of storage since this data structure must be persistent as a key value store. While the differences between Sway and Rust syntax aren’t particularly large in most places, we don’t have access to some of the more functional aspects of Rust like iterators and closures.

One difference that I tend to enjoy relative to the EVM dialects is that I need not encode any data when making external calls to other contracts. The procedure is to import the ABI of the contract you want to call and then we can make a declaration as follows: let contract = abi(IMPORTED_ABI, CONTRACT_ID). Once we have our declaration, we can call any function on the abi. With an external call, we can also choose what native asset we forward with the call besides gas. A native asset is a part of the UTXO set in Fuel. This leads to the other enjoyable difference: UTXO’s are not a part of contract state. As a result, they can be used with unlocking scripts known as predicates and moreover, sending and receiving UTXOs is independent of any interaction with contract state, which reduces state bloat and is safer than traditional ledger-based asset patterns. Lastly, I also enjoy the designated types for contracts, externally owned accounts, and the Identity enum. There isn’t a particularly convenient way to detect whether msg.sender is an EOA or contract in the EVM, but we can do it easily with Sway. Besides the explicit handling of separate types for each, if we need to handle an Identity enum, I can simply use a match statement and handle each case (or match arm) explicitly (Address & ContractId) as one would in Rust.

I had a lot of fun writing in sway for the decentralized bounty board. While I occasionally got stuck, the debugging process was a breeze. The concepts from Sway that will feel the newest will depend on where one is coming from. If you are a smart contract developer used to EVM dialects but haven’t touched Rust, there will be additional adjustments like using unwrap, match statements, generics, and error handling with enums. On the bright side, the learning curve is not nearly as steep as idiomatic Rust. If you know Rust and have written smart contracts in any EVM dialect, learning Sway will be a really smooth process. Make sure you get to know the std library well, it is your best friend. I had a good experience building with Fuel, so go check out Sway!

Check out my Fuel Improvement Proposal, Twitter, & Github

It’s no secret that I’ve been in a real groove with Rust and Rust-based domain specific languages lately. For ETH Denver this year, I had the pleasure of extensively using the Sway programming language to create a decentralized bounty board. Sway is a rust-based DSL for smart contracts using the Fuel Virtual Machine runtime. Despite some wide architectural differences between the EVM and FVM, such as having a UTXO based model, most of the expressions I find myself accustomed to were readily accessible in the standard library (like msg.sender, block.timestamp, msg.value, etc). Fortunately, I felt right at home for a lot of this hackathon while using Sway, despite it being new to me.

Sway smart contracts are typically laid out in four parts using Sway: a declaration of the contract, the ABI which contains the function declarations (like traits in Rust) and storage access patterns, optionally a storage block for variables in storage, and the ABI implementation for Contract. I love this program structure because it feels clear to me where everything fits together, even if we have a few more declarations via macros. User defined types, events, errors, and the ABI can all be placed in separate library files and imported with dep and use statements to reduce clutter inside of the main program.

From the standpoint of idiomatic Rust, there are a couple syntactic differences to keep in mind when using collections in Sway. To retrieve a value at some arbitrary position in a vector, we call .get(…) on the type instead of using brackets and providing the element’s index. Enums will always have a type specified by default, if none, a unit struct. Lastly, HashMaps only exist inside of storage since this data structure must be persistent as a key value store. While the differences between Sway and Rust syntax aren’t particularly large in most places, we don’t have access to some of the more functional aspects of Rust like iterators and closures.

One difference that I tend to enjoy relative to the EVM dialects is that I need not encode any data when making external calls to other contracts. The procedure is to import the ABI of the contract you want to call and then we can make a declaration as follows: let contract = abi(IMPORTED_ABI, CONTRACT_ID). Once we have our declaration, we can call any function on the abi. With an external call, we can also choose what native asset we forward with the call besides gas. A native asset is a part of the UTXO set in Fuel. This leads to the other enjoyable difference: UTXO’s are not a part of contract state. As a result, they can be used with unlocking scripts known as predicates and moreover, sending and receiving UTXOs is independent of any interaction with contract state, which reduces state bloat and is safer than traditional ledger-based asset patterns. Lastly, I also enjoy the designated types for contracts, externally owned accounts, and the Identity enum. There isn’t a particularly convenient way to detect whether msg.sender is an EOA or contract in the EVM, but we can do it easily with Sway. Besides the explicit handling of separate types for each, if we need to handle an Identity enum, I can simply use a match statement and handle each case (or match arm) explicitly (Address & ContractId) as one would in Rust.

I had a lot of fun writing in sway for the decentralized bounty board. While I occasionally got stuck, the debugging process was a breeze. The concepts from Sway that will feel the newest will depend on where one is coming from. If you are a smart contract developer used to EVM dialects but haven’t touched Rust, there will be additional adjustments like using unwrap, match statements, generics, and error handling with enums. On the bright side, the learning curve is not nearly as steep as idiomatic Rust. If you know Rust and have written smart contracts in any EVM dialect, learning Sway will be a really smooth process. Make sure you get to know the std library well, it is your best friend. I had a good experience building with Fuel, so go check out Sway!

Check out my Fuel Improvement Proposal, Twitter, & Github