I view this more as "web apps should not be written in C++ due to security issues that we have long come to understand" than "web apps should be written in C++ due to performance issues we are guessing at"... like, do you believe that in a few years people will decide "no, strongly typed and proof assisted languages were overkill for contracts: it was actually better to code them in a language that has weirdly fluid rules and type semantics for reasons they did not quite grok in 2017"?

This criticism doesn't apply to Ethereum. Solidity is compiled to a VM. You can write other languages that meet your criteria that still use Ethereum.

I know, and I am very excited for those languages to exist and be usable, and thereby have been tracking a couple such efforts; until then, this is about as useful as pointing out that website development is theoretically possible using a computer. The person did not state that it would always be the case that smart contracts are hard: only that right now, on Ethereum, they are hard, and the comment even used "gotten to the point where" (indicating this is a temporary state) and specifically blamed the "tools", which is all absolutely true and is born out not just in theory but in practice; it doesn't even disagree with your own statements that other different tools would be better. Why are you so defensive about this commentary?

I'm like a goalie. Defense is my game.

Actually, I didn't mean to come across as defensive. I just like to nerd out about tech.

Once you accept the inherent craziness of the proposal, and go "Ok, this is crazy. What now?" you end up concluding that the future is going to be very interesting. It'd be worth investing some amount (that you can afford to lose!) in ETH on the off-chance that it doesn't suffer a major disaster. There are quite a few interesting applications for this technology, and historically that's been a pretty solid bet.

The main thing to keep in mind at this point in time is that these contracts have very little tolerance for inefficiency, since inefficiency in this case costs money. Even solidity is very inefficient. Sure it would be great to write contracts in Haskell or Coq but can you insure O(1) or at most O(n) run time with little to no constant overhead? For example LLL (Low-Level Lisp-Like Language) produces 70% more efficient code than solidity [1] and thus it is the chosen language for the ENS (Ethereum Name Service) registry smart contract (who wouldn't want to pay 70 less for interacting with a contract?). But no doubt, better languages will come with time :)

[1] https://media.consensys.net/an-introduction-to-lll-for-ether...

Difference being that a poorly written web app amounts to some leaked passwords and email addresses.

A poorly written smart contract that handles real money, on the other hand...

So? It's their money to lose.

Yes, it's crazy, but it's also happening.

Agreed, and the massive hacks and losses will continue as long as smart contracts are written in Solidity.

The EVM is Turing-complete, so this will be a risk with any language that compiles into a smart contract.

Solidity doesn't appeal to me because its goal seems to be on-boarding JavaScript programmers. But new languages that compile to EVM can be easier to use "safely" and you will see several of these in the next few years.

I'm really excited that a project to embed Turing-complete behavior in a blockchain has actually taken off. It's completely insane from one perspective, but completely awesome from another.

The EVM might be Turing complete but you can still have languages that compile down to only some tractable sub-set of the possible EVM programs.

The interesting question is whether a language can be design which allows the important domain-relevant requirements to written down in an understandable way and also proved rigorously.

So far neither lawyers nor programmers have done a very good job of this in their respective field. Watching people trying to do it in both fields simultaneously sounds like popcorn time to me.

Huh? Lawyers have done an exceptional job. There are huge swaths of activity around which there is consensus about legal dogma.

And huge swaths of activity where programmers have laid out clear deterministic expectations.

If you're saying lawyers have failed to specify the legal ramifications of All Possible Activity then... Sure. So? Even if Ethereum only works for one single narrowly defined contract, it could be immensely useful.

The question for me isn't "where could it fall short" but "where might it measure up?"

The EVM might be turing-complete but since you can only get finite number of execution cycles, you can usually determine the behaviour of your program or if it halts within the current gas limits.

...passwords that might be reused for the email addresses, and paypal, and...

A web app might not touch real money, but a leak can still have real money consequences for the users.

Sure, but in theory I can change passwords and maintain separate credentials for my banking-related needs.

Short of auditing the Solidity contract code myself, there's nothing I can do to protect myself from the hacks themselves because the very mechanism by which money is transferred is riddled with bugs.

This is mostly just semantics anyway - I'm just trying to establish that writing money-transfer software in a poorly designed language is, one way or another, worse than writing a web app in one.

There are also other consequences:

- vulnerabilities can be used to attack users directly or through social engineering

- (rare today, but definitely a problem with C++ web apps) you can break through a hole in the app and pwn the whole server