6 ms·

So let me get this straight: WASM is basically asm.js, but without having to go through javascript? The future has changed! https://www.destroyallsoftware.com

So let me get this straight: WASM is basically asm.js, but without having to go through javascript? The future has changed! https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

adamnemecek 10y ago
I know it's easy to dismiss it but wasm will be th e biggest deal in the world.
- Zikes 10y ago
  There are already talks about compiling Go to wasm: https://github.com/golang/go/issues/18892 https://github.com/golang/go/issues/18892
  - stymaar 10y ago
    I'm not sure I see any interest in that tbh: what's the point of porting a memory-safe (with GC and runtime) on a VM especially dedicated to remove the costly memory safety part of JavaScript. Plus, the concurrent model of Go doesn't really shine if you run it in a single threaded configuration (which is most likely to be the case in wasm). I might be missing something but to me it sounds like pure hype to put go and wasm together.
    - themihai 10y ago
      >> I'm not sure I see any interest in that tbh: Running other languages(than JS) in the browser is interesting for sure.
    - bradfitz 10y ago
      You're confusing concurrency and parallelism. Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be able to write blocking Go code and not worry about callbacks or async/await and let Go's runtime deal with it all while you write concurrent code.
      - stymaar 10y ago
        > You're confusing concurrency and parallelism. I'm not, it's just that the most appealing feature of Go is it's ability to use parallelism for concurrency with a decent overhead, which makes it straightforward to scale vertically. > Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be able to write blocking Go code and not worry about callbacks or async/await and let Go's runtime deal with it all while you write concurrent code. IMO, Async/await is a much cooler pattern than Goroutine + channels do do concurrent stuff on one thread. I find it way easier to use, and less error prone. The drawback is that you need a different paradigm when you want to take advantage of parallelism. Of course it's a matter of personal preferences, but the prevalence of async/await in different programming languages indicates that at least I'm not the only one thinking this way :).
        emn13 10y ago
        async/await is possibly simpler to implement. At least: in go effectively every method is async (at least the api doesn't show what is and is not), and that means you can't afford the inefficiencies that typical async/await implementations have because you'd be paying them all over the place.
    - rubber_duck 10y ago
      >what's the point of porting a memory-safe (with GC and runtime) on a VM especially dedicated to remove the costly memory safety part of JavaScript. a) binary portability - compile and ship WASM link/run on any machine with WASM VM - eg. package up to NPM and run trough any V8 target b) extra sandboxing layer for security (it's designed for browsers where you are supposed to run non-trusted code) c) portable APIs (assuming WASM targets expose the same underlying platform like node or w/e) d) WASM is single threaded right now but from what I've seen it's a top priority for next release to spec out shared memory threads
      - stymaar 10y ago
        I agree with d), but I'm quite skeptical about the other 3. a) and c) means it's portable on everything a JS VM runs on, which is not that much more than what Go runs on. b) is legit, but that really sounds like an overkill.
        rubber_duck 10y ago
        Well a) and c) also means you can run in the browser - client/server code sharing and such can be a really big win.
coldtea 10y ago
>WASM is basically asm.js, but without having to go through javascript? No. It also has non-JS accessible language features, and the article lists several of them.
ojr 10y ago
javascript shows no sign of dying since that talk, more people are doing desktop software (Electron) and more people using js to make native apps (React Native). Node.js is also popular on the server. Babel also took off which lessen the need for compile-to-js languages and makes the future of javascript into more javascript. Javascript is more ubiquitous than ever, wasm is best suited for hardware intensive applications and library authors, this is overkill for normal client side javascript
- acjohnson55 10y ago
  Those techs you mentioned are successful largely because they use Javascript as a runtime. Supposing those runtimes also eventually support WASM (with a good story of linking binaries), I see no reason why other languages won't begin to be used. Perhaps not for a few years though.
Ajedi32 10y ago
> WASM is basically asm.js, but without having to go through javascript? Sort of, but not exactly. See section 2 of the linked article.

adamnemecek 10y ago

I know it's easy to dismiss it but wasm will be th e biggest deal in the world.

Zikes 10y ago
There are already talks about compiling Go to wasm: https://github.com/golang/go/issues/18892 https://github.com/golang/go/issues/18892
- stymaar 10y ago
  I'm not sure I see any interest in that tbh: what's the point of porting a memory-safe (with GC and runtime) on a VM especially dedicated to remove the costly memory safety part of JavaScript. Plus, the concurrent model of Go doesn't really shine if you run it in a single threaded configuration (which is most likely to be the case in wasm). I might be missing something but to me it sounds like pure hype to put go and wasm together.
  - themihai 10y ago
    >> I'm not sure I see any interest in that tbh: Running other languages(than JS) in the browser is interesting for sure.
  - bradfitz 10y ago
    You're confusing concurrency and parallelism. Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be able to write blocking Go code and not worry about callbacks or async/await and let Go's runtime deal with it all while you write concurrent code.
    - stymaar 10y ago
      > You're confusing concurrency and parallelism. I'm not, it's just that the most appealing feature of Go is it's ability to use parallelism for concurrency with a decent overhead, which makes it straightforward to scale vertically. > Even with GOMAXPROCS=1 (1 CPU running Go code), it's very liberating to be able to write blocking Go code and not worry about callbacks or async/await and let Go's runtime deal with it all while you write concurrent code. IMO, Async/await is a much cooler pattern than Goroutine + channels do do concurrent stuff on one thread. I find it way easier to use, and less error prone. The drawback is that you need a different paradigm when you want to take advantage of parallelism. Of course it's a matter of personal preferences, but the prevalence of async/await in different programming languages indicates that at least I'm not the only one thinking this way :).
      - emn13 10y ago
        async/await is possibly simpler to implement. At least: in go effectively every method is async (at least the api doesn't show what is and is not), and that means you can't afford the inefficiencies that typical async/await implementations have because you'd be paying them all over the place.
  - rubber_duck 10y ago
    >what's the point of porting a memory-safe (with GC and runtime) on a VM especially dedicated to remove the costly memory safety part of JavaScript. a) binary portability - compile and ship WASM link/run on any machine with WASM VM - eg. package up to NPM and run trough any V8 target b) extra sandboxing layer for security (it's designed for browsers where you are supposed to run non-trusted code) c) portable APIs (assuming WASM targets expose the same underlying platform like node or w/e) d) WASM is single threaded right now but from what I've seen it's a top priority for next release to spec out shared memory threads
    - stymaar 10y ago
      I agree with d), but I'm quite skeptical about the other 3. a) and c) means it's portable on everything a JS VM runs on, which is not that much more than what Go runs on. b) is legit, but that really sounds like an overkill.
      - rubber_duck 10y ago
        Well a) and c) also means you can run in the browser - client/server code sharing and such can be a really big win.

coldtea 10y ago

>WASM is basically asm.js, but without having to go through javascript? No. It also has non-JS accessible language features, and the article lists several of them.

ojr 10y ago

javascript shows no sign of dying since that talk, more people are doing desktop software (Electron) and more people using js to make native apps (React Native). Node.js is also popular on the server. Babel also took off which lessen the need for compile-to-js languages and makes the future of javascript into more javascript. Javascript is more ubiquitous than ever, wasm is best suited for hardware intensive applications and library authors, this is overkill for normal client side javascript

acjohnson55 10y ago
Those techs you mentioned are successful largely because they use Javascript as a runtime. Supposing those runtimes also eventually support WASM (with a good story of linking binaries), I see no reason why other languages won't begin to be used. Perhaps not for a few years though.

Ajedi32 10y ago

> WASM is basically asm.js, but without having to go through javascript? Sort of, but not exactly. See section 2 of the linked article.