What is the merit of creating new smart contract languages like Solidity instead of using other languages?

Question

What is the pros and cons of creating new languages like Solidity for smart contracts instead of using other computer languages like Golang or Python?

Answer 1

Every programming language is designed for a particular operational environment and target tasks; and these constraints drive almost all design decisions on what features to support and which ones to drop.

A while ago, I've spent quite a lot of time to create a Go -> EVM cross compiler. I did manage to run a few trivial programs and it definitely was a lot of fun, but quite soon I've started to hit the limitations of the EVM that clashes with the core assumptions behind Go:

• Every goroutine needs at least 64KB memory. Trivially low for any decent hardware nowadays, but exorbitantly high and expensive for the EVM.
• Go relies on operating system level memory manager. This means that to run Go programs on the EVM, we'd need to develop a micro memory manager on top of the EVM that can support the operations needed by Go. I designed a POC version of the Buddy Memory Allocation algo, but that one is based on the fact that memory is limited and fixed, and allocates arbitrary chunks within that. The EVM on the other hand is "infinite" and charges per maximum allocated offset. So all usual memory allocation algos would suffer since they assume memory costs are constant whereas the EVM is positional and even exponential at that.
• Go is a garbage collected language, so every memory allocation needs to also maintain reference counters, which need to play well with the memory allocator. Again not impossible to solve, but the associated opcode and non-linear memory costs make this very expensive.
• Even if the memory issues are solved, you'd still need to figure out solutions for synchronization primitives, operating system interrupts and other storage constructs that we tend to take for granted but the EVM does not have.

These challenges were the main ones why I decided against continuing my port of Go to the EVM, but they really highlight that modern languages are based on countless features that the underlying operating systems support, which themselves are based on assumptions about what the underlying hardware is capable of and the associated costs.

The EVM is very different beast from this aspect, so applying the same assumptions leads to highly suboptimal code execution. Hence why the decision was made to develop a language specifically tailored to the EVM execution environment. It is indeed probably a lot more work than porting an existing language syntax (!), but it also results in a usable environment vs. having all kinds of "documented restrictions" that although something is valid Go code, you can't use it because "xyz".

Note, it might very well be the case that the original EVM design is bad and will be extended, upgraded or even fully replaced when someone figures out a much better solution to do things. But that's a future possibility whereas Solidity is a current need.

Answer 2

In particular, in the smart contract world, the code is designed to inter-operate with EVM and hence there are a few key requirements for a language to be used in smart contract.

1. Compiler needs to be able to output code optimized for code-size (while many other languages tend to optimize for computation efficiency).

2. Optimize for security and audit-ability.

Also it is possible there are other organization/social benefits for using a new language, such as

3. A much larger flexibility of your compiler design decisions (no one will try to use existing code on your new compiler and complain it doesn't work)

See the other answer by @Péter Szilágyi for an example of trying to use Go language to cross compile into an EVM bytecode

Reference: Vitalik answers about why a new language in AMA

There are several challenges. First of all, existing c++ and other compilers tend to output code that is really not optimized for compact code size; eg. even the simplest program outputs a file that is longer than 4kb. This is ok for computers, where storage is cheap, but terrible for blockchains, where storage is expensive. So specialized compilers are required

Second, EVM smart contract languages need to be designed with a particularly strong focus on security, which is not something that most existing languages care about to the same extent.

---

I am not sure if it'd be easy for my answer to merge into the @Péter Szilágyi's answer, so I make it a separate one.