Becoming a Blockchain Developer: Does the Smart Contract Language Matter?
With all of the rapid growth and investment funneling into blockchain technology, many aspiring as well as veteran developers want to know how they can improve their skill set by learning about the development process.
Knowing that the development community has a tendency to be opinionated about their tools, techniques, and languages of choice, it’s easy to assume that there will always be various camps that claim that their kung fu is stronger. But does this hold true for blockchain smart contracts?
The term “smart contracts,” popularized by Ethereum, refers to immutable code distributed through the blockchain ledger and executed by the miners when certain conditions are met. Ethereum smart contracts are written in a language called Solidity whose syntax is derived from OOP conventions (similar to C++, C#, and Java) and compiled into bytecode that can be executed by the Ethereum Virtual Machine (EVM).
At a glance it would seem that sticking to familiar scripting languages would be a huge advantage. However, in order to really understand that as an improvement over Solidity, you have to look at the codebase of an Ethereum dapp. Part of the issue is nomenclature — many people erroneously equate smart contracts to dapps. While the contracts may enable the dapp’s token transactions, it’s a very far cry from being the dapp itself. Take a straightforward example like STORJshare, which allows users to either consume or supply crowd-sourced disk storage nodes where transaction fees flow directly from consumer to supplier in the form of STORJ tokens. The Solidity code for the smart contracts can seen on Github.
If you poke around, you’ll notice 2 things:
1) The smart contracts themselves contain very little code. In the grand scheme of most dapps, the smart contract itself makes up a very tiny percentage of the overall codebase and its functionality.
2) the Solidity language has a predictable structure and is relatively easy for any developer to understand the jist of it even if it’s their first time seeing it
The first observation is critical — the smart contract only exists to provide logic for transactions. Here you will find ZERO code that refers to the storage and encryption of shared files, broadcasting a node, or disk usage rules. You really won’t find anything that defines the STORJshare app at all. That’s beacuse that’s not what smart contracts do.
The functional codebase that handles the above components are all located in a separate repository — and guess what, it’s all written in NodeJS.
For the Golem dapp, they’ve created an economy around a distributed computing network that benefits multi-threaded apps such as Blender. The contracts are similarly light, whereas the codebase that does all the heavy lifting is written in Python.
Therefore there is nothing stopping you from writing your Ethereum dapp in any language you choose, including C# or .Net, provided that you can craft the smart contract segment in Solidity. This won’t be a major hurdle for a competent engineering team because of points 1 and 2 above. They won’t even have to deviate from their normal toolset since Visual Studio already has an extension for Solidity.
In other words, the success, performance, and quality of a decentralized software product is far more likely to depend on its core codebase rather than its smart contract; if a product is buggy and/or doesn’t launch on time, I can confidently say it won’t be because the dev team struggled to write a couple of hundred lines of Solidity.
So why do these alternate platforms make such a big deal about it?
Let’s be honest — the majority of new money rushing into blockchain technology is from investors who couldn’t write a “hello world” to save their life. That is true with all technologies, even outside of blockchain. In the current sea of over 1000 alt-currencies, the teams have to be able to differentiate their product to these investors without having to explain the merits of delegated byzantine fault tolerance. I believe in the success of many different approaches to blockchain technology such as Neo and IOTA, so while I find the smart contract development language fairly unimportant, I have to concede that it’s important to find ways to reach more people and gain more adoption.
So in the end, if I had to hire a developer to write smart contracts, I’d bet on a seasoned Java developer learning Solidity on the job long before going with a junior developer who has focused specifically on Solidity for the past 6 months. My advice to the developers is to be open to new techniques and syntax, but stick with the fundamentals of what makes a solid software engineer, and you will have no shortage of opportunities within the blockchain space or otherwise.