I do not really believe in the success of the Vyper language on Ethereum, the problem is that apart from the fact that the language is totally different in syntax, it is more or less a subset of solidity. Such domain specific limited languages always have the problem of scaling: If the architecture limit is reached the only option for scaling is to rewrite everything in another language (like solidity in our case). Instead of designing a brand new language, it would be more practical to define different subsets of the solidity language and check these subsets in compile time. As an example, a secure subset can be considered if we do not have inheritance, loops or foreign smart contract calls. If for some reason the secure subset can not be hold less secure structures of the language can be also used, with increased risk of course.
