I recently saw NEO being advertised as Ethereum but with multiple language support for smart contracts.

Is this really something that Ethereum lacks? Is it not technically possible to build more compilers for smart contracts that generate Ethereum bytecode? I believe there are already three compilers, Solidity, Serpent and LLL.

All of this reminds me of the .NET hype where it was entirely possible to compile any language to JVM but .NET was still being touted as language-independent. Is history repeating itself? Or am I missing something?


  • Hi there. I think what you're asking would lead to subjective and opinion-based answers, which aren't a very good fit for the more specific, technical questions that this board is aimed towards. I think Reddit would probably be a better place to ask: www.reddit.com/r/ethereum :-) Aug 24, 2017 at 16:01
  • Hi, thanks. I guess the second part of my question is open-ended but I still think the question of whether Ethereum lacks multiple language support should be answerable.
    – alexg
    Aug 24, 2017 at 16:19

1 Answer 1


I will attempt an answer at the technical parts of the question. I had the same thought about history repeating itself or writers not knowing what they were talking about when I saw the touting of multiple languages as a feature intrinsic to NEO to the exclusion of Ethereum.

The short answer is no, the lack of language support in Ethereum is not an intrinsic property of Ethereum.

Given that both NEO and Ethereum are Turing-complete, they can, as has been proven, be used to implement each other (the terms we use now were, for perhaps obvious reasons, not used in this paper); that is, even if they can't run the same programs directly, the NEO virtual machine (VM) can simulate an Ethereum virtual machine and vice versa, using the simulated machine to execute the input, with some caveats.

The caveats of the above are indirectly relevant to NEO and Ethereum. The first caveat is that the emulated speed of execution will be slower than a comparable virtual machine; measured in instructions, an Ethereum-native contract will require fewer instructions to execute (and thus cost less gas) than executing a contract emulating the NEO VM running a NEO contract. Of course, doing the latter is silly. We'd just write native code. This leads to the second caveat: not every instruction of a VM may be emulated efficiently by another VM. For example, on computers without floating point units, it is relatively computationally costly to do floating point math -- but it can still be done. Germanely, the introduction of zkSNARKS to Ethereum in Metropolis will enable something to be implemented in contracts that would have been infeasible before. Another caveat is that input/output (I/O) and peripherals available to the virtual machines is not the same -- specifically, an Ethereum VM cannot presently directly interact with the NEO VM and I expect the reverse is also true. There are other caveats that I'll skip over (e.g., memory constraints from porting), but the above are perhaps the biggest caveats.

It is possible that NEO has a larger set of fast-native operations which make it easier to support a larger number of operations efficiently, but if this is found to be useful, I'm sure someone will propose an EIP to add support for the instruction. In the meantime, if one really wanted to write in a particular language, one could also write a cross-compiler (or write a new EVM compiler and optimizer for the parsing frontend of an existing compiler) and add some additional support to handle blockchain I/O such as determining current block number and state management.

Upon some further reading, it appears as though NEO has some I/O features that are part of its VM that are not part of Ethereum's -- specifically, triggers that cause contracts to be run such as firing on a certain date or when another account reaches a particular balance). In NEO, it's a bit like interrupt-driven callbacks; in Ethereum, this can be done (without modifying the EVM) using external polling such as Ethereum Alarm Clock. Of course, this has no effect on what languages are supported or supportable.

  • Thanks that made it very clear for me. I appreciate the answer.
    – alexg
    Aug 25, 2017 at 7:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.