15 ms·

Making WebAssembly better for Rust and for all languages

398 points by petercooper 9y ago

vvanders 9y ago
wasm-bindgen looks Awesome. Definitely the most painful part of using wasm/emscripten and looks like a very clean solution.
kodablah 9y ago
Looking forward to ref types[0] and host bindings[1] so this stuff doesn't get too JS-specific. The former has seen a good bit of activity recently. 0 - https://github.com/WebAssembly/reference-types https://github.com/WebAssembly/reference-types 1 - https://github.com/WebAssembly/host-bindings https://github.com/WebAssembly/host-bindings
netcraft 9y ago
A friend was recently trying to use webassembly from rust and ran into an issue where he couldnt use anything that depended on rust's random - because it depended on a nano scale clock from the system. With problems like meldown/spectre, how could this even be resolved in the future? Would anything that depended on that need to use a random function from js instead?
- wyldfire 9y ago
  Maybe eventually if retpoline robustly resolves the issue of speculative execution, the high precision clock access could be restored?
  - imtringued 9y ago
    Alternatively the problem could be fixed directly in the hardware.
- steveklabnik 9y ago
  So, at first, it will compile, but fail: https://github.com/rust-lang-nursery/rand/pull/197 https://github.com/rust-lang-nursery/rand/pull/197 Then, two weeks ago https://github.com/rust-lang-nursery/rand/pull/272 https://github.com/rust-lang-nursery/rand/pull/272 > Would anything that depended on that need to use a random function from js instead? Your instinct is right, that's what the above does. (more specifically, with https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues https://developer.mozilla.org/en-US/docs/Web/API/RandomSourc... )
Dude2023 9y ago
> This is because JS is a good choice for most things. That's why it's one of few languages: 1) with mainstream transpilation; 2) more than one transpiler.
- amelius 9y ago
  Isn't that simply because, until recently, JS had a "monopoly" on languages you could use inside a browser?
  - burner5692 9y ago
    Yes, that's the only reason anyone has voluntarily used JavaScript.
    - kiriakasis 9y ago
      This, is false. for many (some, if you prefer) use cases javascript is perfect.
  - jerf 9y ago
    If you look at it as "compilation tends to converge on the lowest-level possible output", it all fits pretty well. Dynamic scripting languages flouted that for a long time, but now there's enough JITs floating around that show that even they tend in that direction. So if JS is the lowest possible level language, than that will be the compilation target for a program going into that context. x86 has its many, many critics, but I've never heard any of them say that x86 is bad because so many things compile to it....
- themihai 9y ago
  It's the only language supported by web browsers. That's the reason people still use it.
  - kowdermeister 9y ago
    So how do you explain Node.js being so popular?
kiliancs 9y ago
> we can use the ES module API. With this, working with WebAssembly modules should be as easy as importing them. > import {myFunction} from "myModule.wasm" > We’re working with TC39 and the WebAssembly community group to standardize this. Note that this is already possible using Webpack 4.
- steveklabnik 9y ago
  And Parcel, and hopefully others in the future!
  - k__ 9y ago
    Does it work with Node.js?
    - steveklabnik 9y ago
      Yup! The most recent Node LTS includes wasm support without a flag, previous versions required you to include a flag.
- agnivade 9y ago
  She does mention that with bundlers, users will still use the ES module syntax.
harpocrates 9y ago
One thing that continues to amaze me is that WebAssembly isn't being discussed more outside of the context of the web. Think about it just as a format that (a) is low-level enough to support performance tricks, (b) is fast to turn into native code, and (c) easy to check. Compilers could stop worrying about obscure/old architectures. Deploying an application onto multiple platforms is no longer a problem. Sandboxing is much simpler. Formal verification becomes possible (the WebAssembly spec actually reads like a spec, unlike the C standard which reads more like a religious text). I'm so excited about WebAssembly, but really not because of the web.
- mattcoles 9y ago
  In what way would it noticeably differ from the LLVM IR then?
  - steveklabnik 9y ago
    LLVM IR is not platform independent, for one. See http://webassembly.org/docs/faq/#why-not-just-use-llvm-bitcode-as-a-binary-format http://webassembly.org/docs/faq/#why-not-just-use-llvm-bitco... for the projects' own explanation on this topic. I share the parents' excitement in this regard. The spec is well written for this kind of thing, and I think it has a lot of potential. We'll see!
    - andromeduck 9y ago
      Sounds like JVM
      - KMag 9y ago
        The JVM also forces one to adopt the JVM's high-level object model and use the JVM's garbage collector. Plenty of languages have a large semantic mismatch with Java, and shoehorning them onto the JVM is cumbersome.
        usrusr 9y ago
themihai 9y ago
>> One big 2018 goal for the Rust community is to become a web language. Without DOM access I fail to see how that would happen. So until WASM gets DOM access no other language(except JS) can become a(first class) web language. What is JavaScript without DOM access?
- steveklabnik 9y ago
  You can access the DOM, but you have to call into JS, which adds some overhead. When people say “DOM access,” they mean native, not through JS. Check out the stdweb crate. Even then, there's tons of logic you want to execute in the browser that aren't related to UI. For example, any sort of number crunching. That stuff is now feasible, which opens up all kinds of applications.
  - TomasSedovic 9y ago
    To add a specific example here, I've recently compiled a roguelike I'm working on to WASM, not knowing what to expect when I started. This required only a handful of changes across the codebase (mostly handling external resources such as the filesystem and the random generator) and then implementing a bit of JavaScript that took the drawcalls from the WASM core and rendered them on the canvas. And vice-versa, a bit of JS that passed the browser input into the WASM game. Since the original game had no concept of a DOM, it didn't matter to it. I think WASM can be huge for browser games. But like Steve said, you can call any JavaScript function and manipulate the DOM that way. At least for Rust, there's also a library that does this for you. So you can have Rust code that uses a DOM API and the WASM <-> JS bridge is handled for you: https://github.com/koute/stdweb https://github.com/koute/stdweb
    - seanmcdirmid 9y ago
      Does WASM provide a canvas API at least (i.e. something more advanced than pushing pixels to a buffer)?
      - steveklabnik 9y ago
e12e 9y ago
> One of the hardest parts of working with WebAssembly is getting different kinds of values into and out of functions. That’s because WebAssembly currently only has two types: integers and floating point numbers. So... The only overlap between Javascript and webassembly is floating point numbers? Are they the same type of floating point? And is the conversion unicode-string > js float > ws int - or something else? Or does js have integers now?
- zdragnar 9y ago
  Typed arrays are available in JS, originally for webgl support, and enhanced (I think?) for web assembly.
- echeese 9y ago
  JS doesn't have integer, but its Number is really just a double, which has a 52 bit mantissa, meaning it can hold any 8, 16 or 32 bit integer. Only 64 bit integers are unable to be stored in a double, which is why the WASM->JS interface doesn't allow them.
prewett 9y ago
The article talks about being able to integrate into the JavaScript "ecosystem," but for me the excitement of WebAssembly is that I can avoid JavaScript and an object system that is fundamentally unsuitable for anything other than static word-processor-like documents. (Which, to be fair, is what HTML was designed to be.) We know how to write a UI library, I think the basic components are pretty well-defined. Qt and NextStep (surviving to some extent in Cocoa) are well-regarded. Java Swing is okay. So if we could get a real UI library for use in the browser, instead a JavaScript framework poorly re-inventing it, that would be wonderful. And, best of all, it doesn't have to be in JavaScript!
- Felz 9y ago
  I think bypassing the entire DOM would be ultimately a good thing. There's no real choice in webdev; we are all shackled to a rickety and cobbled together mountain of legacy code. Browsers should always have been a well defined VM with everything else built on top. I'm hoping we can get away from being shackled to what Microsoft, Google, and even Mozilla think is necessary and important for developing software. What we'll lose of course is interoperability. But I think it will be worth it.
  - flavio81 9y ago
    You are 100% right.
  - kiriakasis 9y ago
    This would fail. > What we'll lose of course is interoperability. But I think it will be worth it. Maybe i misunderstood, but what is the web without interoperability?
- ZenPsycho 9y ago
  Why does nobody think of accessibility when they indulge in these weird 1980's-style-ui-library-in-a-browser fantasies?
  - swsieber 9y ago
fnord77 9y ago
> This is because JS is a good choice for most things. It really isn't, though. Maybe less bad with ES6. I feel like this was thrown in to mollify the scores of people who <strike>wasted their lives with</strike> invested a lot into javascript. I know the unfortunate story of how javascript came to be the "web language". It's a shame even a tiny bit more thought didn't go into it.

398 points by petercooper 9y ago

wasm-bindgen looks Awesome. Definitely the most painful part of using wasm/emscripten and looks like a very clean solution.

kodablah 9y ago

Looking forward to ref types[0] and host bindings[1] so this stuff doesn't get too JS-specific. The former has seen a good bit of activity recently. 0 - https://github.com/WebAssembly/reference-types https://github.com/WebAssembly/reference-types 1 - https://github.com/WebAssembly/host-bindings https://github.com/WebAssembly/host-bindings

netcraft 9y ago

A friend was recently trying to use webassembly from rust and ran into an issue where he couldnt use anything that depended on rust's random - because it depended on a nano scale clock from the system. With problems like meldown/spectre, how could this even be resolved in the future? Would anything that depended on that need to use a random function from js instead?

wyldfire 9y ago
Maybe eventually if retpoline robustly resolves the issue of speculative execution, the high precision clock access could be restored?
- imtringued 9y ago
  Alternatively the problem could be fixed directly in the hardware.
steveklabnik 9y ago
So, at first, it will compile, but fail: https://github.com/rust-lang-nursery/rand/pull/197 https://github.com/rust-lang-nursery/rand/pull/197 Then, two weeks ago https://github.com/rust-lang-nursery/rand/pull/272 https://github.com/rust-lang-nursery/rand/pull/272 > Would anything that depended on that need to use a random function from js instead? Your instinct is right, that's what the above does. (more specifically, with https://developer.mozilla.org/en-US/docs/Web/API/RandomSource/getRandomValues https://developer.mozilla.org/en-US/docs/Web/API/RandomSourc... )

Dude2023 9y ago

> This is because JS is a good choice for most things. That's why it's one of few languages: 1) with mainstream transpilation; 2) more than one transpiler.

amelius 9y ago
Isn't that simply because, until recently, JS had a "monopoly" on languages you could use inside a browser?
- burner5692 9y ago
  Yes, that's the only reason anyone has voluntarily used JavaScript.
  - kiriakasis 9y ago
    This, is false. for many (some, if you prefer) use cases javascript is perfect.
- jerf 9y ago
  If you look at it as "compilation tends to converge on the lowest-level possible output", it all fits pretty well. Dynamic scripting languages flouted that for a long time, but now there's enough JITs floating around that show that even they tend in that direction. So if JS is the lowest possible level language, than that will be the compilation target for a program going into that context. x86 has its many, many critics, but I've never heard any of them say that x86 is bad because so many things compile to it....
themihai 9y ago
It's the only language supported by web browsers. That's the reason people still use it.
- kowdermeister 9y ago
  So how do you explain Node.js being so popular?

kiliancs 9y ago

> we can use the ES module API. With this, working with WebAssembly modules should be as easy as importing them. > import {myFunction} from "myModule.wasm" > We’re working with TC39 and the WebAssembly community group to standardize this. Note that this is already possible using Webpack 4.

steveklabnik 9y ago
And Parcel, and hopefully others in the future!
- k__ 9y ago
  Does it work with Node.js?
  - steveklabnik 9y ago
    Yup! The most recent Node LTS includes wasm support without a flag, previous versions required you to include a flag.
agnivade 9y ago
She does mention that with bundlers, users will still use the ES module syntax.

harpocrates 9y ago

One thing that continues to amaze me is that WebAssembly isn't being discussed more outside of the context of the web. Think about it just as a format that (a) is low-level enough to support performance tricks, (b) is fast to turn into native code, and (c) easy to check. Compilers could stop worrying about obscure/old architectures. Deploying an application onto multiple platforms is no longer a problem. Sandboxing is much simpler. Formal verification becomes possible (the WebAssembly spec actually reads like a spec, unlike the C standard which reads more like a religious text). I'm so excited about WebAssembly, but really not because of the web.

mattcoles 9y ago
In what way would it noticeably differ from the LLVM IR then?
- steveklabnik 9y ago
  LLVM IR is not platform independent, for one. See http://webassembly.org/docs/faq/#why-not-just-use-llvm-bitcode-as-a-binary-format http://webassembly.org/docs/faq/#why-not-just-use-llvm-bitco... for the projects' own explanation on this topic. I share the parents' excitement in this regard. The spec is well written for this kind of thing, and I think it has a lot of potential. We'll see!
  - andromeduck 9y ago
    Sounds like JVM
    - KMag 9y ago
      The JVM also forces one to adopt the JVM's high-level object model and use the JVM's garbage collector. Plenty of languages have a large semantic mismatch with Java, and shoehorning them onto the JVM is cumbersome.
      - usrusr 9y ago

themihai 9y ago

>> One big 2018 goal for the Rust community is to become a web language. Without DOM access I fail to see how that would happen. So until WASM gets DOM access no other language(except JS) can become a(first class) web language. What is JavaScript without DOM access?

steveklabnik 9y ago
You can access the DOM, but you have to call into JS, which adds some overhead. When people say “DOM access,” they mean native, not through JS. Check out the stdweb crate. Even then, there's tons of logic you want to execute in the browser that aren't related to UI. For example, any sort of number crunching. That stuff is now feasible, which opens up all kinds of applications.
- TomasSedovic 9y ago
  To add a specific example here, I've recently compiled a roguelike I'm working on to WASM, not knowing what to expect when I started. This required only a handful of changes across the codebase (mostly handling external resources such as the filesystem and the random generator) and then implementing a bit of JavaScript that took the drawcalls from the WASM core and rendered them on the canvas. And vice-versa, a bit of JS that passed the browser input into the WASM game. Since the original game had no concept of a DOM, it didn't matter to it. I think WASM can be huge for browser games. But like Steve said, you can call any JavaScript function and manipulate the DOM that way. At least for Rust, there's also a library that does this for you. So you can have Rust code that uses a DOM API and the WASM <-> JS bridge is handled for you: https://github.com/koute/stdweb https://github.com/koute/stdweb
  - seanmcdirmid 9y ago
    Does WASM provide a canvas API at least (i.e. something more advanced than pushing pixels to a buffer)?
    - steveklabnik 9y ago

e12e 9y ago

> One of the hardest parts of working with WebAssembly is getting different kinds of values into and out of functions. That’s because WebAssembly currently only has two types: integers and floating point numbers. So... The only overlap between Javascript and webassembly is floating point numbers? Are they the same type of floating point? And is the conversion unicode-string > js float > ws int - or something else? Or does js have integers now?

zdragnar 9y ago
Typed arrays are available in JS, originally for webgl support, and enhanced (I think?) for web assembly.
echeese 9y ago
JS doesn't have integer, but its Number is really just a double, which has a 52 bit mantissa, meaning it can hold any 8, 16 or 32 bit integer. Only 64 bit integers are unable to be stored in a double, which is why the WASM->JS interface doesn't allow them.

prewett 9y ago

The article talks about being able to integrate into the JavaScript "ecosystem," but for me the excitement of WebAssembly is that I can avoid JavaScript and an object system that is fundamentally unsuitable for anything other than static word-processor-like documents. (Which, to be fair, is what HTML was designed to be.) We know how to write a UI library, I think the basic components are pretty well-defined. Qt and NextStep (surviving to some extent in Cocoa) are well-regarded. Java Swing is okay. So if we could get a real UI library for use in the browser, instead a JavaScript framework poorly re-inventing it, that would be wonderful. And, best of all, it doesn't have to be in JavaScript!

Felz 9y ago
I think bypassing the entire DOM would be ultimately a good thing. There's no real choice in webdev; we are all shackled to a rickety and cobbled together mountain of legacy code. Browsers should always have been a well defined VM with everything else built on top. I'm hoping we can get away from being shackled to what Microsoft, Google, and even Mozilla think is necessary and important for developing software. What we'll lose of course is interoperability. But I think it will be worth it.
- flavio81 9y ago
  You are 100% right.
- kiriakasis 9y ago
  This would fail. > What we'll lose of course is interoperability. But I think it will be worth it. Maybe i misunderstood, but what is the web without interoperability?
ZenPsycho 9y ago
Why does nobody think of accessibility when they indulge in these weird 1980's-style-ui-library-in-a-browser fantasies?
- swsieber 9y ago

fnord77 9y ago

> This is because JS is a good choice for most things. It really isn't, though. Maybe less bad with ES6. I feel like this was thrown in to mollify the scores of people who <strike>wasted their lives with</strike> invested a lot into javascript. I know the unfortunate story of how javascript came to be the "web language". It's a shame even a tiny bit more thought didn't go into it.