While looking at the interoperability/token bridge space, it becomes apparent very quickly that the “low hanging fruit” is connecting EVM-based blockchains.
The moment a bridge needs to occur to non-EVM, such as Solana, there appear to be challenges because develops don’t get any free-riding. They need to deal with a different language (Rust) and any implication of a different virtual machine (not sure what those are and if those add costs).
If looking just at the language/DSL comparison, it does seem that integrations and smart contract development in Rust vs Solidity leans towards Rust.
A more complete development tool chain for Rust plus some hackable-elements of Solidity, make Rust a better approach.
However, what is interesting is the potential for WASM VMs: different languages could be compiled to the same WebAssembly target, which opens up different languages for smart contracts.
Given some of the benefits of WASM for just regular server-side development -- sandboxed environments, secure abstraction from underlying OS/CPU, near-native speeds, support for multiple compiled languages -- this seems like a reasonable direction.
A few issues remain to be seen:
- Performance comparison, which was not favorable for WASM EVM
- Turing complete vs Non-Turing complete - this article makes the case re: infinity loops
I share the same conclusion at this article by pulling back and seeing what’s best for the overall smart contract industry. Supporting multiple language, a standard adopted by browsers, and low-overhead runtime for traditional cloud deployments make it a key bridge to widespread adoption for hybrid contracts, where the contracts may need logic portably executed in a browser, blockchain, and a public cloud.