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), 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.

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

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, it seems you could potentially use other compilers to generate a Application Binary Interface.

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.

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.