Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WASM instead of Typescript #6157

Closed
olanod opened this issue Jun 7, 2020 · 5 comments
Closed

WASM instead of Typescript #6157

olanod opened this issue Jun 7, 2020 · 5 comments

Comments

@olanod
Copy link

olanod commented Jun 7, 2020

I guess it's a bit late now, but couldn't have not only the runtime be written in Rust but also every other API and be compiled to WASM? in the longer term it would translate in faster start-up times better more predictable performance. I imagine the community could later create a WASM version of the std and any other API right? or are there major blockers that make it hard to do?

@lucacasonato
Copy link
Member

This is not what WASM is for.

@olanod
Copy link
Author

olanod commented Jun 9, 2020

How is it not a legitimate usage of WASM? What is the one valid usage you have in mind? I don't think there is one specific task WASM is meant to do, is a very general purpose low level virtual machine that a few years down the line will be available and running absolutely everywhere, embedded hardware, operating systems, cloud, blockchain, docker replacement, you name it. The web and being JavaScript's sidekick was a facade, this bad guy had mayor plans from the beginning, is far from reaching its full real potential.

As a Deno user what do you care if the standard library or any library is written in one language or another, it could have all been native Rust to get the best performance possible but then you suffer from a bloated runtime, to keep it slim and not force its users to use the std Deno can provide it in a format that is very portable like JS/Typescript which it happens to support, but there is also WASM that will give you smaller modules that you'll be waiting less to download, will be much faster to parse, compile and optimize and will give you better or at least more predictable performance.

Perhaps in its current state WASM is a bit rough around the edges and not ideal to integrate, a Rust library for example will be compiled using wasm bindgen that wraps the binary with some JS glue that loads the WASM binary and gives you higher level API, but those issues will quickly fade when say *.wasm imports are allowed and interface types or equivalent gets standardized, most likely you'll end up using import maps and not even managing your dependencies directly so little you'll care what language your dependency is written with when you import foo from 'super-foo'.

@kitsonk
Copy link
Contributor

kitsonk commented Jun 9, 2020

Duplicate of #5961, #1980 and a few other suggestions like #5591.

Running Rust as compiled Rust will always be faster than run Rust compiled to Web Assembly. It is only something you do when you can't run Rust as part of the binary. For code authored in JavaScript, Web Assembly is not a good target, as JavaScript is a GC'ed language (plus a lot of other stuff) which all have to be re-implmented in WASM and then in theory better than V8.

@olanod
Copy link
Author

olanod commented Jun 17, 2020

I doesn't look clear to me how this is a duplicate of those issues but .. 🤷‍♂️
It's not about compiling TS/JS to WASM, but mostly about not using TS/JS and only Rust compiled to WASM, at least for the std lib and important libraries.

@kitsonk
Copy link
Contributor

kitsonk commented Jun 17, 2020

Rust compiled to Web Assembly would run slower than Rust. Writing all of the std in Rust is not ideal, as it is hard to make effective JavaScript/TypeScript interfaces in WASM. It also makes contribution complex, and it is cumbersome. Moving critical hot paths to Rust or Web Assembly makes sense, which was just done with hashes: https://github.com/denoland/deno/blob/master/std/hash/_wasm/src/lib.rs but does not require a meta issue to be open for that. If there are specific hot paths you wish to contribute or you think need to be moved over, then a specific issue is far more appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants