5 ms·
Do you have any actual interesting critiques of the wasm bytecode format and what it has failed to learn from Java bytecode or CLR bytecode or whatever? Because
by mort96 3y ago
Do you have any actual interesting critiques of the wasm bytecode format and what it has failed to learn from Java bytecode or CLR bytecode or whatever? Because that would be interesting, and I'm sure there are design choices to analyze and criticise. Empty references to the potential existence of problems isn't very interesting though.
- pjmlp 3y agoStart with Burroughs Large Machines from 1961, do a stop at Xerox PARC, visit ETHZ, Bell Labs, Amsterdam University, Caltech, Tao Group, UCSD, IBM and Unisys mainframes, Microsoft R&D, and already there are several bytecodes to look into. The hype around WebAssembly is also not very interesting for those of us that have read hundreds of papers on those bytecodes, but hey there is VC money to burn.
- jrockway 3y agoI think that network effects win over technical merit every time, and this time WebAssembly has the momentum. I think it's pretty neat that you can take a web server written in C++, implement some new compression algorithm in Go, and then have that web server compress pages with your Go code without having to recompile the webserver or touch any of its code. That's what WebAssembly outside of the browser offers; you can just write stuff in your language of choosing for other products. All the VC hype just means that everyone picked the same backend so there is some possibility of traction. In reality, some flaws are preventing adoption. C and Rust are pretty much the only viable languages with WebAssembly support, and since those are also the chosen implementation languages for runtime, nobody is really deriving this benefit. (Anything with a runtime seems to fail for programs beyond "hello world".) (I tried a "real program" and WebAssembly once, but it ran out of memory when compiled with either gc or tinygo. We had to write the browser side of things in Javascript, which was a shame. The code in question was: https://github.com/pachyderm/pachyderm/blob/master/src/internal/archiveserver/encode.go#L22 https://github.com/pachyderm/pachyderm/blob/master/src/inter.... Somewhat complex, but not so complex you can't do it in Javascript. So a bit of a shame that WebAssembly didn't work out.) The other thing that I think WebAssembly should fix (but people seem to want to kill me when I mention this) is that the Typescript compiler should just output WebAssembly and we can forget about node_modules and Webpack and that whole nightmare. There is AssemblyScript, but it doesn't run React, so doesn't matter for this use case. Someday I will go insane and just compile node or deno to WebAssembly and just ship the whole VM with my app embedded in it. Then you'll have a real reason to want to kill me! Muahahaha.
- mort96 3y agoThere's some cool stuff going on with GC in WebAssembly, which should really help bring higher level languages efficiently to WASM: https://v8.dev/blog/wasm-gc-porting https://v8.dev/blog/wasm-gc-porting.
- pjmlp 3y agoSome of those bytecodes were already polyglot, this idea is as old as UNCOL, from 1958. https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/UNCOL
- baq 3y ago> hey there is VC money to burn. given the absolute idiocy some of them finance WASM is a paragon of sensibility and should be injected money via IV. special mentions go out to softbank, tiger global and a16z.
- mort96 3y agoI know that there are existing bytecodes. I'm asking what you think WebAssembly should have learned from them but didn't. But based on your response I'm guessing you don't really have that kind of thoughtful critique of WebAssembly?
- pjmlp 3y agoHere is one, despite all the security marketing, programs inside the sandbox can still be tricked into internal memory corruption, as there is no way to prevent bounds checking inside the same linear memory segment. So they are bound to black box attacks, where a clever sequence of function calls can eventually result in something being allowed that wasn't before, as the internal memory state of the WASM module is now corrupt.
- CyberDildonics 3y agoYou have no sources or evidence for these claims because they aren't true.
- pjmlp 3y ago"Everything Old is New Again: Binary Security of WebAssembly" https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... One of many security presentations, finding the others is an exercise for the reader that actually cares about security.
- CyberDildonics 3y agoThis doesn't say what you're claiming. It just says that webasm stack frames are next to each other like C. A C program that crashes will crash in webasm.
- pjmlp 3y agoThanks for confirming not having any clue in Infosec.
- CyberDildonics 3y agoWhat is your actual technical criticism?
- pjmlp 3y agoSelling WASM as the solution of all problems in the world, and being the first at anything.
- CyberDildonics 3y agoWhere did anyone say any of that?
- pjmlp 3y agoPlenty of people selling WebAssembly as if the first of a kind across social media and VC backed products. Now we even get kubernetes with WASM containers redoing IBM mainframes/micro computers, Java and .NET application servers as if never done before.
- CyberDildonics 3y agoI think you're hallucinating this, you have no links. Also, this isn't technical criticism that I asked for. Who cares what "people are saying" anyway? What is your technical criticism?
- pjmlp 3y agoNo, I am not doing your work, that is all.
- CyberDildonics 3y agoI see we've reached the "prove my claims for me" section.
- kouteiheika 3y ago> Do you have any actual interesting critiques of the wasm bytecode format and what it has failed to learn from Java bytecode or CLR bytecode or whatever? I'm not OP, and I don't know if you could have figured this out by just looking at the bytecode formats that came before it, but I think the biggest design mistake of WASM is most likely it being a stack machine. It gives very little (if any?) practical benefits and it just massively complicates everything, both the compilers and the VMs. I'm not speculating here. I have a pet VM that I'm developing for a register-based IR which achieves roughly the same execution performance of guest programs as wasmtime, but compiles them into native code 160 times faster, doesn't compromise on security, has a bytecode format which takes roughly as much space as WASM, and with an implementation that is vastly less complex (wasmtime's Cranelift is ~150k lines of code; my codegen is, maybe, ~2k lines of code, depending on how you count).
- mort96 3y agoThis is a good one. I'm not an expert (I've written a few toy VMs, some stack-based and some more register-like, but nothing focused heavily on optimization) but I've also heard that stack-based bytecode formats are pretty much strictly worse than register-based ones.