Another Solidity alternative is Vyper. It is statically typed, safe, Pythonic approach.<p><a href="https://vyper.readthedocs.io/en/stable/" rel="nofollow">https://vyper.readthedocs.io/en/stable/</a><p><a href="https://twitter.com/vyperlang" rel="nofollow">https://twitter.com/vyperlang</a><p>Vyper is being used in Curve and Yearn (both billions of dollars of TVL): <a href="https://ethereum.org/en/developers/docs/programming-languages/python/" rel="nofollow">https://ethereum.org/en/developers/docs/programming-language...</a>
For those not familiar with Solidity, there is a peculiarity in the "ABI" that makes it painful to interop between languages.<p>In solidity, there are types called "contracts" which are like classes in other languages. When you call a function in a different contract, the dispatch is routed using the first few bytes of the has of the signature [1].<p>For example, to transfer ERC-20 tokens you dispatch using `hash(transfer(address, uint256))[:4]`, meaning that you put those first four bytes at the beginning of the data that you pass to the receiving contract.<p>Just like the native world, this causes a problem when you try to interface between different languages. In Fe, the types have different names so this hashing scheme can't work without a translation layer. From some of the issues it looks like interoperability may be a problem [2]. That's ok if you write all the contracts that your dApp interacts with, but as time goes on dApps interact and call into one another more and more often.<p>There are probably also lots of opportunities here for exploiting confusion at these boundaries, so if you're inclined and know how to use tornado you may be able to make quite a bit of money off contracts that use Fe.<p>[1] <a href="https://docs.soliditylang.org/en/v0.8.10/abi-spec.html#function-selector" rel="nofollow">https://docs.soliditylang.org/en/v0.8.10/abi-spec.html#funct...</a><p>[2] <a href="https://github.com/ethereum/fe/issues/592" rel="nofollow">https://github.com/ethereum/fe/issues/592</a>
To any Fe developers reading this: please put a non-trivial code snippet of Fe, with code comments that highlight the improvements over Solidity, front and center on the README.<p>I am a longtime smart contract developer who has been burned by Solidity’s downsides so I am excited about new EVM languages. I’ve read the Fe README, the announcement blog post, and the Uniswap v2 examples, but still have no concrete set of improvements over Solidity that I can point to. Maybe it’s just because things are still early, but from 15 minutes looking at Fe it still seems like Solidity but this a Pythonic syntax. As a Solidity dev, I want to see concretely how Fe improves on my existing smart contract language.<p>Thank you for pushing the frontier on smart contract development! I feel we’re in the very beginning of smart contract development and languages like Fe can be the path towards preventing tons of these hacks we see every week.
I started studying Solidity recently and found that code sharing and reuse is done through inheritance.<p>What's the reasoning behind this? I thought we have a lot of documentation about inheritance being bad, but in Solidity not only this is core, but multiple inheritance is also core. This is then combined with (occasional) implicit access to permanently stored data, and with something that I can only describe as function inheritance.<p>While discovering this, I started having the thought that it was done on purpose (easy to find faulty contracts that could be hacked for money). This was a nasty thought, indeed, but I found a lot of anti-features.
> Decidability by limitation of dynamic program behavior<p>This claim sounds suspicious. If the authors really solved this, they have a bright future. A turing award for sure.
And still not a single example of a good real world use case. I would love to be proven wrong, but all answers to this question I have seen so far devolve into a bunch of self-referential babble that leaves you no wiser at the end of it.<p>And I'm saying this as a fan of cryptocurrencies and someone who wants to see them succeed.
Wait, the cryptocurrency community is going back to smart contracts? I thought the hype had died down there after (1) the DAO hack showed that smart contracts are nothing more than self-funded bug bounties, and (2) the founders using social pressure to override the DAO contract showed that smart contracts are just as vulnerable to human interpretation as any real contract.