5 ms·

How important is the adoption of Solidity for Ethereum's success?

52-6F-62 9y ago
I've been reading a lot about Ethereum, and I am really interested in blockchain tech -- but I also wonder about this. I am really curious as to whether it would be possible to develop new languages for the handling of smart contracts, or if it is possible to develop smart contracts (using a library or other resource) with existing, popular languages like c++, python, or javascript. I know web3 is already quite accessible and while I haven't looked at the source, it seems relatively easy to work with. But the core language for smart contracts... I think Eth would benefit from some flexibility on the development end. Or maybe I just don't know enough. Anyway, I think that would be a big leap.
- RexetBlell 9y ago
  I know that Consensys (who is looking to hire hundreds of engineers https://consensys.net/open-positions/ https://consensys.net/open-positions/) is working on a special smart contract language that would be easy for lawyers to learn. The language compiles into EVM bytecode.
- DennisP 9y ago
  There are several languages that compile to the EVM. Also there's a somewhat speculative project to transition to a restricted version of WASM, which would let languages like C and Rust be compiled into smart contracts on Ethereum.
  - 52-6F-62 9y ago
    Interesting. All I knew of previously was Solidity, and it seemed... practical but limited. That said, I haven't done a deep dive yet. Thanks
Breefield 9y ago
I made this website. I don't know the answer to your question. If you cruise down to "The Solc Compiler" on this page https://www.ethereum.org/greeter#cleaning-up-after-yourself https://www.ethereum.org/greeter#cleaning-up-after-yourself, it seems you could potentially use other compilers to generate a Application Binary Interface.
RexetBlell 9y ago
I don't think it's very important. There are several other languages that can compile down to EVM bytecode. A cool one is Viper (https://github.com/ethereum/viper https://github.com/ethereum/viper), which is NOT Turning complete, but decidable. This makes it easier to reason about the correctness of the code, and formally proving that your code is correct.
- metroidfan832 9y ago
  several? Really? Please link me other languages that compile to EVM bytecode.
  - Jabanga 9y ago
    Ethereum developers use Solidity almost exclusively, because it is by far the most developed, but there is also Serpent, Viper and LLL. I don't know if Serpent and LLL are still being actively developed. Yoichi Hirai is also developing Bamboo [1]. [1] https://github.com/pirapira/bamboo https://github.com/pirapira/bamboo
merrickread 9y ago
Solidity is just the first try. I built a couple projects and ideas with it - found it to be a very uncomfortable language. On the other hand you have Hyperledger, it's "contract" code is Go. Widely adopted language that was basically designed for networking efficiency.
kbody 9y ago
I'm quite surprised by the answers. The truth is that Ethereum's success comes from the seemingly ease of the Solidity. It made it possible to have a crazy amount of developer jump in. As a Node.js developer, it was effortless to start coding with Solidity. But that's part of the problem; it seems so easy, but there are no safeguards and a lot of traps. That's why we get so many flawed contracts that were taken advantage of/hacked and ICOs delaying their distribution or processes because a bug was found. 90s cypherpunks that gave birth and worked on these ideas of smart-contract etc. saw the things a bit more responsibly, instead of development velocity on something that proves unsustainable even from a security perspective not to mention scalability-wise. Here is are some thoughts from one of the originals - Christopher Allen co-author of TLS standard. I'm disappointed in the corruption of the term Smart Contracts. Bitcoin's Script, and in particular P2SH is a good start to them, but massive multiple execution of arbitrary code is not (aka IBM's Chain Code), and I would even argue that Ethereum's languages are not smart contracts either—just another chain code. I do agree that business logic is hard to do with Bitcoin's Script, but for all of us talking about Smart Contracts in the late '90's (Szaboian Smart Contracts?) we desired cryptographic composabilty, that the code could be analyzed at multiple levels to be secure (from language proofs to high level business logic atomic validation), limitable (i.e. expression complexity & evaluation cost can be determined) and could often just be validated by consensus of parties not every node in the world (which only at most need to see proof of execution, not the full contract). These would be true cryptographic Smart Contracts! https://twitter.com/ChristopherA/status/715197498646593536 https://twitter.com/ChristopherA/status/715197498646593536

I've been reading a lot about Ethereum, and I am really interested in blockchain tech -- but I also wonder about this. I am really curious as to whether it would be possible to develop new languages for the handling of smart contracts, or if it is possible to develop smart contracts (using a library or other resource) with existing, popular languages like c++, python, or javascript. I know web3 is already quite accessible and while I haven't looked at the source, it seems relatively easy to work with. But the core language for smart contracts... I think Eth would benefit from some flexibility on the development end. Or maybe I just don't know enough. Anyway, I think that would be a big leap.

RexetBlell 9y ago
I know that Consensys (who is looking to hire hundreds of engineers https://consensys.net/open-positions/ https://consensys.net/open-positions/) is working on a special smart contract language that would be easy for lawyers to learn. The language compiles into EVM bytecode.
DennisP 9y ago
There are several languages that compile to the EVM. Also there's a somewhat speculative project to transition to a restricted version of WASM, which would let languages like C and Rust be compiled into smart contracts on Ethereum.
- 52-6F-62 9y ago
  Interesting. All I knew of previously was Solidity, and it seemed... practical but limited. That said, I haven't done a deep dive yet. Thanks

Breefield 9y ago

I made this website. I don't know the answer to your question. If you cruise down to "The Solc Compiler" on this page https://www.ethereum.org/greeter#cleaning-up-after-yourself https://www.ethereum.org/greeter#cleaning-up-after-yourself, it seems you could potentially use other compilers to generate a Application Binary Interface.

RexetBlell 9y ago

I don't think it's very important. There are several other languages that can compile down to EVM bytecode. A cool one is Viper (https://github.com/ethereum/viper https://github.com/ethereum/viper), which is NOT Turning complete, but decidable. This makes it easier to reason about the correctness of the code, and formally proving that your code is correct.

metroidfan832 9y ago
several? Really? Please link me other languages that compile to EVM bytecode.
- Jabanga 9y ago
  Ethereum developers use Solidity almost exclusively, because it is by far the most developed, but there is also Serpent, Viper and LLL. I don't know if Serpent and LLL are still being actively developed. Yoichi Hirai is also developing Bamboo [1]. [1] https://github.com/pirapira/bamboo https://github.com/pirapira/bamboo

merrickread 9y ago

Solidity is just the first try. I built a couple projects and ideas with it - found it to be a very uncomfortable language. On the other hand you have Hyperledger, it's "contract" code is Go. Widely adopted language that was basically designed for networking efficiency.

kbody 9y ago

I'm quite surprised by the answers. The truth is that Ethereum's success comes from the seemingly ease of the Solidity. It made it possible to have a crazy amount of developer jump in. As a Node.js developer, it was effortless to start coding with Solidity. But that's part of the problem; it seems so easy, but there are no safeguards and a lot of traps. That's why we get so many flawed contracts that were taken advantage of/hacked and ICOs delaying their distribution or processes because a bug was found. 90s cypherpunks that gave birth and worked on these ideas of smart-contract etc. saw the things a bit more responsibly, instead of development velocity on something that proves unsustainable even from a security perspective not to mention scalability-wise. Here is are some thoughts from one of the originals - Christopher Allen co-author of TLS standard. I'm disappointed in the corruption of the term Smart Contracts. Bitcoin's Script, and in particular P2SH is a good start to them, but massive multiple execution of arbitrary code is not (aka IBM's Chain Code), and I would even argue that Ethereum's languages are not smart contracts either—just another chain code. I do agree that business logic is hard to do with Bitcoin's Script, but for all of us talking about Smart Contracts in the late '90's (Szaboian Smart Contracts?) we desired cryptographic composabilty, that the code could be analyzed at multiple levels to be secure (from language proofs to high level business logic atomic validation), limitable (i.e. expression complexity & evaluation cost can be determined) and could often just be validated by consensus of parties not every node in the world (which only at most need to see proof of execution, not the full contract). These would be true cryptographic Smart Contracts! https://twitter.com/ChristopherA/status/715197498646593536 https://twitter.com/ChristopherA/status/715197498646593536