expr_callto the expression traversal that assigns the function's return type to
I have been following the Fe project for a while (I initially thought that the Vyper compiler is being re-worked on as the Fe project using Rust. Seems like it has evolved now).
I'm the maintainer of https://vyper.fun project (CryptoZombies, but for Vyper).
If you guys want to create a resource like CryptoZombies for Fe, just let me know. I can create one :smile:
<Christoph Burgdorf (cburgdorf)> Hey @vbuterin happy to see you here!
Syntactically, the difference are numbered at this point. E.g. we where vyper uses decorators to declare public functions we currently use
pub def something:, we choose angle brackets for generics e.g
map<TKey, TVal> which is used more widespread for generics (Rust, C#, TypeScript etc). Vyper is limited by the AST that the Python parser produces wheres Fe has a rather flexible parser. Many syntax decisions aren't yet set in stone but I think Fe will arrive at a mix of Python and simplified Rust.
I personally don't have an opinion on LLL but considering that Solidity is currently the de-factor standard and that it is working towards using YUL by default (currently already used for inline assembly) we believe it will give us a shortcut in terms of adoption. If YUL will allow targeting eWASM, OVM etc, we will benefit from it immediately. Plus, if the last stage of our processing pipeline is going from YUL to bytecode then I believe this may also be an advantage for auditing if it means that the last stage of compilation is basically the same as in Soliditiy. That isn't true yet because Solidity doesn't yet use YUL by default but I think that we will eventually arrive at that place.
Using Rust also eliminates a whole category of errors that could can arise at runtime compared to one written in Python. It also gives us a much nice way of distributing binaries of the compiler.
Lack of code re-use features such as: Modifiers (re-usable assertions) Method resolution and class inheritance (though we're on the fence about this) Module imports Strict enforcement of limits on dynamic behavior -- Though we aim to provide Vyper's decidability by default, we believe it may also be useful to allow disabling of decidability features if the expressivity trade-off doesn't make sense for certain projects.
<Christoph Burgdorf (cburgdorf)> Interesting memory library for solidity
<Christoph Burgdorf (cburgdorf)> https://axic.github.io/notes/summit/future_of_solidity/
Interesting slides on soliditys future. Nice to see some overlap in our plans (e.g std library)