cc: @BrendanEich
-
-
Replying to @caspy7 @ParityTech
WebAssembly was designed under single-system, low-level compiler target & JS VM constraints. Nothing like decentralized-via-blockchain smart contract constraints. I'm still w/ Dan Boneh on latter wanting pure functional lang over state machine transitions: https://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/ …
2 replies 7 retweets 34 likes -
People won't write Wasm contracts by hand. We can have a pure functional language Smart Contracts targeting Wasm for that purpose - in fact that would be really cool!
2 replies 0 retweets 8 likes -
BrendanEich Retweeted JF Bastien
As
@jfbastien pointed out (https://twitter.com/jfbastien/status/1009579882920071168 …), this means you did not need WebAssembly in full. But the extra degrees of freedom thereby unnecessarily bundled add cost in complexity, code size, security attack surface. The winning trick to design is *leaving things out*.BrendanEich added,
JF Bastien @jfbastienReplying to @BrendanEichRight: if your approach is to do WebAssembly minus all the things, then you might as well build a language from scratch. That's daunting for most, and definitely not buzzword-compliant
'cuz srsly Rust in WebAssembly on blockchain smart contracts to power my IoT is
3 replies 4 retweets 27 likes -
Replying to @BrendanEich @MaciejHirsz and
Ignore Wasm and all the thought, speccing, tooling, testing and auditing that has gone into it because we need to remove float and it has a few extra opcodes than we strictly need? Whatever happened to standing on the shoulders of giants?
1 reply 0 retweets 9 likes -
Replying to @gavofyork @MaciejHirsz and
Be serious. Is the goal to support multiple languages that can target wasm? If to the contrary (in view of DAO & Parity vulns which motivate a radically different smart contract language/VM), the goal is more like what Dan Boneh described, then you're standing on wrong shoulders.
2 replies 1 retweet 5 likes -
Replying to @BrendanEich @gavofyork and
Can we stop knocking down straw men? Multiple language support is not the goal (a goal maybe, but we already kind of have it with EVM). VM performance, leveraging LLVM for compiler backend and having accesses to at least one mature language safer than Solidity are the goals.
1 reply 1 retweet 8 likes -
Replying to @MaciejHirsz @gavofyork and
No strawmen. Saying “LLVM” implies if not polyglot then C++ or Rust (which uses LLVM but for which LLVM was not great fit at first/even now)-like smart contract language. I question that implicit goal. If you take Dan Boneh’s critique to heart, you want something quite different.
3 replies 1 retweet 4 likes -
Replying to @BrendanEich @gavofyork and
LLVM means I can design a language for smart contracts, write a compiler frontend that outputs LLVM IR and have a neatly optimized Wasm bytecode. Solc isn't particulary good at optimizing things, and it doesn't have much elbow room for it anyway due to EVM restrictions.
1 reply 0 retweets 0 likes -
Replying to @MaciejHirsz @gavofyork and
I definitely agree on EVM & solc issues. It may seem I’m arguing for more of same; I’m not. The goods of LLVM & wasm must be weighed against the bads of attack surface & over-generality. Whittling down has risks, too. It might help to list higher level goals not spelled L L V M.
1 reply 1 retweet 2 likes
Just for what it’s worth, for everything short of a traditional AOT compiler where runtime perf is paramount, I go to Cretonne these days.
-
-
Replying to @pcwalton @MaciejHirsz and
Thanks. My opinion is that p2p immutable blockchain lang+vm is parsecs away from trad AOT compiler/target.
0 replies 2 retweets 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.