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.
This seems to be the direction Gavin Woods is advocating, and the systems are being implemented for this WASM based approach to blockchains.
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
- ...
Conclusion
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.