It is misleading to describe etheteum as Turing-complete. If it were, an infinite while loop would soon crash the network. (As mentioned in the article, the pro

It is misleading to describe etheteum as Turing-complete. If it were, an infinite while loop would soon crash the network. (As mentioned in the article, the processing of Ethereum contracts is powered/funded by a finite valuable currency called gas) A novelty of the unfolding blockchain revolution is the realisation that there is a world of interesting non-turing-complete things to be built. We all assumed that anything non-turing-complete a waste of time. Surprise! What you want to say here is that ethereum takes a large step towards creating a flexible development platform. EVM function like an instruction-set for this distributed computer. This may be close to the way forward. But solidity is not. A quick port of JavaScript, it is still in the old software mindset. Ethereum has problems ahead of it. Just as C has an endless capacity to create memory leak bugs, Solidity offers opportunity for contracts that will drain people's accounts. Each time it happens, it will be reputational damage for the community. If you wanted to learn Ethereum, it might make more sense to start with raw EVM than Solidity. Play at writing a macro assembler. Once you were tooled up, you might try your hand at becoming the Brendan Eich of the blockchain. Until you do, we are stuck with Brendan Eich. If we do not find such an expression, general-purpose, public-access blockchain will gain permanent mistrust, and fail. Message-driven concurrency is here to stay though. I am building a concurrency language centred around message-driven consensus-engines. (github.com/solent-eng/solent) It is designed to be host-distributed, but operated by a single party and not multi-party.