3 ms·

I think that misses part of the point. WASM meets their feature needs. WASM is at the core of it. But, they needed a widely accessible language to tell people

by mfer 6y ago

I think that misses part of the point. WASM meets their feature needs. WASM is at the core of it. But, they needed a widely accessible language to tell people to use. This helps with examples and guidance. They chose AssemblyScript due to their customers being familiar with JS. It looks like I could write what I need in Go or Rust, for example, and build for WASM. They’re just not putting that up front. This is about making an easy path for most people. The way it’s put together is about n making their customers successful rather than building all that’s possible

pantelisk 6y ago
In my experience GO is not a good language for WASM. The simplest wasm binary you will create, will be at least ~3mb in size, even if it only prints "hello world", because GO will need to embed its internals and the garbage collector in the wasm bundle. In a browser scenario this is not particularly attractive... It's really a pity especially since Go is marketed as "a better C". So far C/C++ has been the best optimal target for wasm. Rust on the other hand is extremely promising but I don't have enough experience with it or data to make a case for or against :) AssemblyScript looks amazing though. One thing to consider is that many times you do not need to make your whole project in wasm. Instead you should find crucial bottlenecks (eg matrix math for light calculations, or some blur operation, or some physics calculation or whatever) and take that part out and put it in wasm. That part may already be written in JS and might be very difficult to rewrite in C (time consuming, web dev team might have weak C skills, tougher to debug). For such a scenario AssemblyScript looks fantastic, and this is actually the most common scenario I 've personally encountered (and sometimes I 'd end up writing asm.js by hand or go and recreate my logic in C...). So yeah, I have not used AssemblyScript yet but there are many pain points that a good implementation could blow away. edit: what I describe above is for browser scenarios. I have not used wasm outside of the browser (didn't find a reason to, since I can run native binaries compiled specifically for the target OS - why add one more layer of complexity through wasm?). So, outside of the browser, your experiences might be different.
- tankenmate 6y ago
  TinyGo builds WASM fine from my experience. There are a few minor gotchas (especially running in the browser with callbacks, but that can affect a number of languages compiled to WASM) but it does work.
jariel 6y ago
It's not missing the point if TS is a bad fit for WASM, which it kind of is. Frankly, it's not really TS, it's an odd, unofficial subset of it - kind of like hacking some nice things about TS to 'make it work'. Not only is there the fact that it's OO, it needs a VM, it doesn't even support Strings ... so many questions marks. V8 as it turns out is a pretty good black box. Every one of us runs completely untrusted code on our machines ever day. Pretty most (all?) Shopify staffers and devs are, every day, running untrusted JS code on V8. So it's nice to see progress, and I can't wait to see more details, but it looks tricky from the start ... and TS was never going to be the obvious starting point for WASM.

by mfer 6y ago

pantelisk 6y ago

In my experience GO is not a good language for WASM. The simplest wasm binary you will create, will be at least ~3mb in size, even if it only prints "hello world", because GO will need to embed its internals and the garbage collector in the wasm bundle. In a browser scenario this is not particularly attractive... It's really a pity especially since Go is marketed as "a better C". So far C/C++ has been the best optimal target for wasm. Rust on the other hand is extremely promising but I don't have enough experience with it or data to make a case for or against :) AssemblyScript looks amazing though. One thing to consider is that many times you do not need to make your whole project in wasm. Instead you should find crucial bottlenecks (eg matrix math for light calculations, or some blur operation, or some physics calculation or whatever) and take that part out and put it in wasm. That part may already be written in JS and might be very difficult to rewrite in C (time consuming, web dev team might have weak C skills, tougher to debug). For such a scenario AssemblyScript looks fantastic, and this is actually the most common scenario I 've personally encountered (and sometimes I 'd end up writing asm.js by hand or go and recreate my logic in C...). So yeah, I have not used AssemblyScript yet but there are many pain points that a good implementation could blow away. edit: what I describe above is for browser scenarios. I have not used wasm outside of the browser (didn't find a reason to, since I can run native binaries compiled specifically for the target OS - why add one more layer of complexity through wasm?). So, outside of the browser, your experiences might be different.

tankenmate 6y ago
TinyGo builds WASM fine from my experience. There are a few minor gotchas (especially running in the browser with callbacks, but that can affect a number of languages compiled to WASM) but it does work.

jariel 6y ago

It's not missing the point if TS is a bad fit for WASM, which it kind of is. Frankly, it's not really TS, it's an odd, unofficial subset of it - kind of like hacking some nice things about TS to 'make it work'. Not only is there the fact that it's OO, it needs a VM, it doesn't even support Strings ... so many questions marks. V8 as it turns out is a pretty good black box. Every one of us runs completely untrusted code on our machines ever day. Pretty most (all?) Shopify staffers and devs are, every day, running untrusted JS code on V8. So it's nice to see progress, and I can't wait to see more details, but it looks tricky from the start ... and TS was never going to be the obvious starting point for WASM.