Solidity is NOT JavaScript

As blockchains are expanding their influence, it's quite evident for an ordinary developer that Solidity has almost nothing to do with JavaScript.

I'm very particular about compile-time checks and runtime safety when it comes to writing software, and it becomes apparent if you read my other posts. In 2018, when I first came across Ethereum, also known as the 'world computer,' I knew nothing about the technologies behind it except that I'd need to use Solidity for this computer. The Solidity language website v2.2.0 stated, "Solidity is a high-level language whose syntax is similar to that of JavaScript, and it is designed to compile to code for the Ethereum Virtual Machine."

The reference to JavaScript alarmed me. How come someone use a potentially risky language like JavaScript to manage money? I know it mentioned only the syntax, but the reference was strong enough to discourage further exploration in that area, given at that time it didn't look something worth attention.

However, it turned out to be the complete opposite: Solidity is a type-safe, runtime-safe language that only shares a C-like syntax with JavaScript. Sadly, I discovered this three years later.

I was going to provide some examples here, but I quickly realized that it makes no sense due to the massive differences at the conceptual level. Things like number overflow, limited or no string operations, explicit number casting, manual data location specification, limited local memory, and fixed-sized arrays—none of these are applicable to JavaScript.

Seriously, these things only make sense in Solidity (though not always a good idea):

  • Thoughtfully design the memory layout when inheriting a class for your delegate implementation.
  • Change the order of variables to align them in words and reduce the cost of reading and writing operations to storage.
  • Pack array indexes into u256 using binary operations to save on gas.
  • Check variable values to avoid overflow and underflow.

If anything, to me, Solidity is very close to C-- with the memory management in terms of syntax and proximity to the "hardware" but couldn't be further from JavaScript.