The most compelling part of Radix from a developer's perspective is the introduction of Aspect Oriented Programming. You can read my recent blog post on this subject of you need a primer on the concepts, but the short form is that the compiler and runtime do extra work to make sure that the programmer has not obviously lost, duplicated or otherwise mismanaged the assets they are under their code's care. But coming up with this idea is just the beginning. You have to make it practical by refining how you implement it.
In the earliest conceptions of Scrypto, tokens would be created and passed around and the compiler would reason about their use according to the Asset-Oriented model. This approach can work but at some point the Radix team had a better idea. Buckets and Vaults can hold all the tokens!
Unlike with Ethereum and other protocols, Radix tokens are not defined inside of smart contracts. Instead they are defined in the Radix Engine which makes them first class citizens in the ecosystem. This is fantastic and leads to many benefits that ultimately simplify the jobs of developers creating DeFi Dapps. It also drastically improves overall system security. However a drawback is that the compiler must make some assumptions about how tokens operate in order to enforce the Asset-Oriented model. If the Radix team decided to add another entirely different type of token or resource into the system, then the compiler's assumptions about how resources work may no longer be correct.
Fortunately the Radix team came upon a brilliant way around this potential problem. They created a new rule that all resources in the system (including all tokens and asset control badges), must reside within specific constructs designed for holding them. There are three major types of holding constructs. Accounts are wallets and wallet-like third party token holders. are the holders that hang onto assets persistently within a smart contract (also known as a 'component' in Radix parlance.) Finally there are . These are temporary constructs that hold tokens while they are being processed in various ways and/or sent to and from Accounts or other Components.
Brilliant! Now the compiler and runtime only have to understand how buckets, vaults and accounts work and then perform their special processing analysis that ensures that developers are creating code that always manages resources properly. Furthermore, now a new type of resource can be added easily and, as long as it can be handled in the normal ways by the holding constructs, everything simply works!
This model with Buckets, Vaults and Accounts is a central aspect of Scrypto today. It all seems to work and serves as key value add for developers. Could it be better? Probably. For one thing the APIs for these different holders are not thoroughly documented suggesting that they are still being refined. Refinement may be in order too as in a few places they use fairly different APIs to perform similar functions. While I expect those issues to be resolved for the Alexandria release (which is slated for December 14th), some of the details may not be pinned down until closer to Babylon as new types of resources such as NFT tokens are, as expected, being added to the Radix Engine.
Whatever changes are made, the Radix development team has to make sure everything remains solid. Based on what I have seen thus far from this team, I have no doubt that they will do so. So far it seems that the Scrypto language is going to deliver stunning multiples in terms of development efficiency to the crypto space. If you want to join the legions that are jumping onto it, you can get the latest version here. You can also join a free community with almost 300 fellow travelers at the Rust & Scrypto Forum on Discord.
(Photo by Himesh Mehta
