7 ms·

The underlying platform is ahead-of-time compiled WebAssembly but AssemblyScript, a variant of TypeScript, will be the only supported language: > Theoretically

The underlying platform is ahead-of-time compiled WebAssembly but AssemblyScript, a variant of TypeScript, will be the only supported language: > Theoretically any language with a Wasm target can be supported, but the effort developers spend to conform to our API is better focused on solving problems for merchants. That’s why we’ve chosen to provide first class support to a single language that includes tools that get developers up and running quickly.

johnnycerberus 6y ago
Like always, browsers are a funny ecosystem and very unpredictable. In all this time I thought that I could see a rise in the adoption of C and Rust libs by the community through WASM but now instead we are building around AssemblyScript. Touche.
- remram 6y ago
  We just have to compile Rust and C to AssemblyScript, à la asm.js, and come full circle (again).
- coding_lobster 6y ago
  It's interesting that this seems on one hand "unpredictable" while also being logical. If a company has employees familiar with TypeScript (or even JS) and they have to make a choice between yet another flavor of that or a new language like C/Rust... well the choice is understandable. Once again the path of least resistance to a new web technology ended up being JavaScript - it just wasn't immediately obvious when WASM first emerged.
  - HoolaBoola 6y ago
    I know I'm deliberately misinterpreting you, but > a new language like C is a funny thought ^_^
  - woodpanel 6y ago
    A JavaScript SuperSet becoming the de facto standard of writing for WASM - I think one can file this under „worse is better“.
    - sitkack 6y ago
      JavaScript SubSuperSet
- enos_feedler 6y ago
  Yes, funny ecosystem and unpredictable because smart people contribute innovative and interesting things. This is the best feature of an open, truly shared ecosystem. Everyone owns it and feel safe contributing to it. The web rules!
  - mekkkkkk 6y ago
    I wish I could share your enthusiasm. Good on you. To me the web of today is an ever-expanding ball of shit being rolled in different directions by giant corporations. I agree it's fun to work with, but it isn't healthy.
    - enos_feedler 6y ago
      I agree with your take on the web today. I am trying to do my part to promote the things outside that bubble. I thought this was a good place to do that :)
- grayrest 6y ago
  I've spent a good amount of time this last year playing around with WASM options in anticipation of it being a major runtime environment for cloud computing. Rust has the most developed ecosystem but the best experience I've had otherwise was with Zig. It's reasonably easy to write and can produce excellent final wasm size. The only problem is that the compiler is currently exporting every public symbol in the standard library but when I hacked up the compiler to only export a hard coded list of symbols I got ~150 bytes for add (the WASM hello world) and easily sub 1k for the type of modules the post is discussing.
  - kfrncs 6y ago
    Do you have a fork of the compiler online?
    - grayrest 6y ago
      No and it's not useful. It's literally just editing `src/link/Wasm.zig` and changing the `--export-all` line to `--export=addInc` (to use the zig wasm example's naming) and copy/pasting the line if I wanted to export more stuff. The compile invocation is: zig build-lib add.zig -O ReleaseSmall -target wasm32-freestanding -static You can debug the linker invocation with `--verbose-link` on the end of that. The issue tracking the problem is: https://github.com/ziglang/zig/issues/7133 https://github.com/ziglang/zig/issues/7133
- robertlagrant 6y ago
  I'm keen on Kotlin Multiplatform. Seems like a pipe dream that might have legs.
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.

johnnycerberus 6y ago

Like always, browsers are a funny ecosystem and very unpredictable. In all this time I thought that I could see a rise in the adoption of C and Rust libs by the community through WASM but now instead we are building around AssemblyScript. Touche.

remram 6y ago
We just have to compile Rust and C to AssemblyScript, à la asm.js, and come full circle (again).
coding_lobster 6y ago
It's interesting that this seems on one hand "unpredictable" while also being logical. If a company has employees familiar with TypeScript (or even JS) and they have to make a choice between yet another flavor of that or a new language like C/Rust... well the choice is understandable. Once again the path of least resistance to a new web technology ended up being JavaScript - it just wasn't immediately obvious when WASM first emerged.
- HoolaBoola 6y ago
  I know I'm deliberately misinterpreting you, but > a new language like C is a funny thought ^_^
- woodpanel 6y ago
  A JavaScript SuperSet becoming the de facto standard of writing for WASM - I think one can file this under „worse is better“.
  - sitkack 6y ago
    JavaScript SubSuperSet
enos_feedler 6y ago
Yes, funny ecosystem and unpredictable because smart people contribute innovative and interesting things. This is the best feature of an open, truly shared ecosystem. Everyone owns it and feel safe contributing to it. The web rules!
- mekkkkkk 6y ago
  I wish I could share your enthusiasm. Good on you. To me the web of today is an ever-expanding ball of shit being rolled in different directions by giant corporations. I agree it's fun to work with, but it isn't healthy.
  - enos_feedler 6y ago
    I agree with your take on the web today. I am trying to do my part to promote the things outside that bubble. I thought this was a good place to do that :)
grayrest 6y ago
I've spent a good amount of time this last year playing around with WASM options in anticipation of it being a major runtime environment for cloud computing. Rust has the most developed ecosystem but the best experience I've had otherwise was with Zig. It's reasonably easy to write and can produce excellent final wasm size. The only problem is that the compiler is currently exporting every public symbol in the standard library but when I hacked up the compiler to only export a hard coded list of symbols I got ~150 bytes for add (the WASM hello world) and easily sub 1k for the type of modules the post is discussing.
- kfrncs 6y ago
  Do you have a fork of the compiler online?
  - grayrest 6y ago
    No and it's not useful. It's literally just editing `src/link/Wasm.zig` and changing the `--export-all` line to `--export=addInc` (to use the zig wasm example's naming) and copy/pasting the line if I wanted to export more stuff. The compile invocation is: zig build-lib add.zig -O ReleaseSmall -target wasm32-freestanding -static You can debug the linker invocation with `--verbose-link` on the end of that. The issue tracking the problem is: https://github.com/ziglang/zig/issues/7133 https://github.com/ziglang/zig/issues/7133
robertlagrant 6y ago
I'm keen on Kotlin Multiplatform. Seems like a pipe dream that might have legs.

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.