Criticism on Vyper

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.  

Comparing Vyper to solidity

Vyper is the brand new language of Ethereum. It aims to repair the problems of solidity especially regarding the security vulnerabilities. It is a simple contract based language, meaning one contract one file without any possibilities for inheritance, or cross-contract communication. The most important elements are the following:

Variables: variables are similar to solidity, the exception is that there is only public or the default visibility which is private. The atomic types are more or less the same, one exception is however that there are no shorthand types, like uint for uint256, or string for a byte array. One advantage is though that there is already decimal.  

publicVariable: public(uint256)

privateVariable: int256

Functions are transactions as usual, one difference is certainly, the syntax is rather similar to the python syntax and not to javascript. Two more differences are that you must always explicitly include the function visibility which is @public or @private. 

@public

def myFunction(_input1: uint256, _unput2: uint256) -> uint256:

    return _input1 - _unput2

self keyword: if you want to refer to a state variable in your function, you can do only do it with explicitely marking with the self.variableName.

Constructor has a special name shown as __init__:

@public

def __init__

Events are similar to solidity events, the only difference is that you define them and raise them with different syntax:

MyEvent: event({_param1: uint256, _param2: uint256})

log.MyEvent(1,2)

Structs are similar to solidity, the only exception is that you can not use them dynamically as types, they are rather types and instantized variables in the same time. 

exampleStruct: {

    value1: int128,

    value2: decimal

}

self.exampleStruct.value1 = 1

Error handling is much simplified. There is an assert that works similarly to solidity, however no other such error handling function is to be found. 

assert 1 == 1

Loops: there are just a special kind of loop in Vyper that guarantees that the loop will end in a certain number of steps.

for i in range(0, 30):

Other elements of the language are pretty much similar to solidity. There aren't fallback functions, the possibility is to call another function of another smart contract is pretty limited (raw_call). There is a low level function to duplicate a code contract, but otherwise there is not really a dynamics contract creation pattern.