DSLs for Ethereum Contracts | Hacker News Reader

DSLs for Ethereum Contracts

michaelburge.us

76 pointsMichaelBurge15 comments

Laughed out loud at the language Pyramid being a Scheme. Perhaps not the best choice for layman marketing, but you got me.

https://www.michaelburge.us/2017/11/28/write-your-next-ether...

I assumed that it was intentional

I'm looking forward to the Red[1] C3 project[2]. Red is a powerful language. I think they stand a chance to do some interesting things in the blockchain space.

1: https://www.red-lang.org 2: https://ico.red-lang.org/RED-whitepaper.pdf

There's also AxLang. It's a core DSL based on Scala. Enables formal verification. Live demo on the public ETH mainnet:

https://medium.com/axoni/axlang-formally-verifiable-smart-co...

Despite being based on semi-functional programming language Scala, I found no evidence that the language AxLang has anything to do with formal verification. I may be wrong, but what I see now is lots of promises without any details.

How do you mean? There are examples of formal verification working in the video. The resulting compiled smart contracts are on the live Ethereum blockchain.

Not related to Ethereum, but I've done some small prototyping of how smart contracts without side effects could be implemented in JavaScript and all compiling to it languages, even the pure functional ones https://github.com/slavasn/bloqly

Just having an actually sane language (as opposed to Solidity) would do wonders. Does anyone here use Viper or similar in production?

I've only recently gotten into the cryptocurrency scene - what about Solidity feels less sane?

They may have changed it in recent versions, but for a long while, functions were public by default (i.e. anyone can call them). Defaulting to open is a huge security flaw and the reason behind the Parity bug https://blog.comae.io/the-280m-ethereums-bug-f28e5de43513

Embark now supports both Vyper and Bamboo:

https://embark.status.im/news/2018/05/03/embark-3-0-released...

Solidity as a language is not that bad. It wouldn't be my first choice but it wouldn't be my last.

Most of the challenges are not at the language level, they're at the EVM level. Any languages on top of the EVM are hamstrung by the EVMs limitations. If it were as easy as "just throw Rust/Go/Java on top of it", that would have already been done.

What do you see as the biggest flaws in the EVM as such?

I think a lot of the difficulty is that it's such a novel runtime environment, and it's going to take a few design/failure iterations to come up with a programming model which fits it.

The biggest flaw: EVM allows integer overflow. This has been responsible for many hacks. (aka somehow withdraw 1 token from 0 token account, now you have LOTS token!) I can't even imagine what they were thinking...

You're right, that's a big one.

Reply on news.ycombinator.com