Our Vision for Rust and WebAssembly | Hacker News Reader

Our Vision for Rust and WebAssembly

rustwasm.github.io

196 pointsJoshTriplett40 comments

>So we are writing The Rust and WebAssembly Book.

Awesome! What's there already is looking good. I wonder if it'll turn into an actual paper book some day like the second edition of TRPL did. [0]

On that note, my copy just shipped today (or at least received a tracking number), so get yours now!*

Alternatively TRPL is also free[1] of course, and there's a somewhat outdated PDF version[2] available. If you're motivated, you can just use that person's scripts to generate an updated copy probably. The advantage of those is that the online and unofficial PDF versions have colorized syntax; the no starch press edition does not last I checked. However, there's no reason not to buy it anyways if you're able. Personally nothing beats paper.

[0] https://nostarch.com/Rust

[1] https://doc.rust-lang.org/book/

[2] https://github.com/lise-henry/books

* = No conflict of interest exists here, Steve is just really nice to me on HN and I love Rust. :)

> my copy just shipped today

Hooray! I got to actually hold one last week, it was... wonderful. I am biased though :p

Congrats!

You know I just realized, if there's ever a revised print edition it'll likely be sold as a second edition, and that'll make it the second edition of the second edition.

Thanks!

We’re changing the naming for this exact reason, the next iteration of the book is being called the “2018 edition” to match with the new edition scheme generally.

The linked nostarch page shows only 13 of 20 chapters as (AVAILABLE NOW). How is the printed book finished already?

Thinking they just haven't updated the page. The e-book itself is probably complete I'm sure.

Also my order shipped now, so it's done and in the mail.

They just didn’t do the final upload; the text was finalized like six weeks ago. The idea was to do it at the same time the physical books shipped. If it’s not already fixed, should be done very soon. I’ve had the PDF in my inbox for a few weeks.

Mine just shipped as well. Very excited! I don't typically buy PL books since they seem to get outdated as opposed to design/architecture type books, but I just had to make an exception for TRPL.

IMHO things like WASM, web vr, and LLVM are all converging this year after years of cool demos, prototypes and gradual progress. Having Rust out there as a first class citizen is awesome. This year we should see the beginning of a minor revolution in front end development, where essentially anything targeting LLVM will be able to compile to WASM, be bundled as an NPM, and be usable in the context of web application for essentially anything done in javascript until now whether it is performance critical algorithms, manipulating the dom, writing to canvas, driving IO via web sockets, dealing with web gl and web vr, audio, etc.

Breaking the monopoly Javascript has had on this space for close to 25 years is a good thing. Perhaps people will continue to use it but it will have to be on merits rather than just merely being the only game in town. In any case looking forward to having more choice in this space.

IMHO, modern JS based frontend development is a combination of tedious, error prone, and backwards. If this honestly is the state of the art, then WTF. happened in the past 20 years.

There is one huge change here (as compared to things like the golang wasm port) which makes this more likely to be adopted IMO:

Rust compiled to WebAssembly doesn’t have a runtime. This results in small .wasm binary sizes that are proportional to the amount of Rust code that is being compiled to WebAssembly. Binary size is of huge importance since the .wasm must be downloaded over the network. The proportionality means you only pay (in code size) for what you use. In turn, that means it is feasible for existing JavaScript code bases to incrementally and partially adopt Rust.

Great to hear they're taking this approach. I do think it'd be nice to have DOM access too though, as then you won't need JS at all - I do think long term the attraction of this is to replace JS as a front-end language, not just augment it, but it's nice they're taking an incremental approach.

It depends how you define "runtime", though.

If you use Rust strings, you may get a large amount of code included to handle them. Also, if you use malloc, that adds a significant amount of code.

It's true that languages like Rust have fewer runtime requirements than languages like Java but none of them are 100% proportional to the code you wrote.

wasm-bindgen is forward compatible with the host bindings proposal, so once that lands, the DOM stuff will Just Work.

Waiting for this !

"as compared to things like the golang wasm port" -- I have two questions here. First, can you elaborate the difference between the current Golang was port and proposed Rust wasm port? Secondly, can you elaborate why Golang port can't have small .wasm size?

Go has a mandatory runtime (think, the GC) that needs to be included, Rust does not. As such, it’s binaries will always be larger.

I remember I watch a talk on youtube saying browser vendors may start make their GC runtime support GC languages (such as Golang, Java), after which we don't need a large Runtime when we consume the WASM compiled from GC languages.

Probably it's far away down the road? But I was under the impression that it will soon get supported.

Wasm has “add a GC” to its roadmap, but a runtime is more than just a GC. That will certainly help, but it’s not a panacea.

What Steve said!

Also (and this does apply to Rust to some extent too), if you start pulling in the stdlib for your webapp then you can't avoid compiling in a lot of code (for example the fmt or net/http packages are pretty big - fmt adds around 1MB to binaries on my system here). If the stdlib for any of these popular languages could be cached or included somehow in browsers that'd be awesome, as part of the attraction of using them is having a great stdlib.

It'd be great if at some point they managed to slim it down significantly as I'd really love to replace JS with Go specifically.

I am not sure what WebAssembly has to do with "breaking the monopoly Javascript has had on this space". It always has been possible to target JavaScript from your compiler. Sure, WebAssembly is a better compiler target, but it does not enable anything.

For example, ClojureScript compiles to JavaScript. Clojure didn't need WebAssembly to do so.

I think it's cool that in a lot of ways JavaScript has "converged" as well. 5 years ago I was a hater like all the other cool kids, but JS today is a fantastic language in my opinion. There are still warts, for sure. But I enjoy writing ES6 almost as much as Python, and for a lot of things I enjoy it more.

I agree with your two first paragraphs. I want to share some elements to complete your outlook.

Javascript, despite having monopoly on the client side since 2007, only saw its usage exploded with Node and NPM around 2013. Java applets and Flash were long dead by then. So it seems that JS success is only partially correlated to its hard-won monopoly on the client side. My intuition is that JS ecosystem cannot be that bad and win so many hearts. Using your words, it seems JS won based on some merits.

A few others clues: Hot reloading, fast build time, good debugging and profiling tools, lots of packages, plenty of already answered problems on stackoverflow/github, progressive complexity, multiple approaches possible from FP to OOP, particular attention to the developer experience (error messages, colors...), good set of linting tools with Typescript or Flow, easy to deploy/deliver, works to make desktop/mobile/web/VR apps, customizable build accessible to mortals, good enough package manager, evolving language that understood that it can always do better, welcoming and accessible dev community, mature networking APIs, good runtimes implemented by different companies...

I've been in this space pretty much throughout the whole period. Applets never took off as a serious option. They peaked briefly around 2000, then flash took over and by 2005 Ajax happened and JS took over.

As for build times, modern javascript is like having all of the disadvantages of a tedious build process without most of the advantages. You are spending the time, yet still don't have static type analysis and exclusion of whole categories of bugs. The reality is that, mostly for political reasons, javascript was the only thing that ran in a browser and after particularly MS (but certainly not them alone) ran into trouble with security issues, nobody really dared to do much else for a long time. Plugin APIs were deprecated, proprietary browser specifics were abandoned, etc.

So, what's happening now is a long over due correction where people compile to some heavily optimizable subset of js called wasm. As soon as that becomes commomplace the whole argument for javascript needs to be revisited, pretty much for the first time this century.

> In the most performance-sensitive contexts, JavaScript hinders rather than helps. Its dynamic type system and non-deterministic garbage collection pauses get in the way. Seemingly small code changes can result in drastic performance regressions if you accidentally wander off the JIT’s happy path.

I'm seeing this repeated more and more as a compelling case for using WASM. I've even repeated it myself. Does anyone know of examples of JS optimized for one VM not performing well in others, leading to a significant cost? I ask this as a Rust/WASM fanboy. Not doubting; just curious. I feel like I've already read a couple anecdotes but can't remember.

I haven't done any performance-critical JavaScript for two years now and I know a lot a things have change with Turbofan, but I had been hitting slow paths of V8 so many times … The easiest to avoid were also the most painful when it comes to code organization : exception handling was so slow it was unusable. And it was affecting our ability to use modern JS, because the polyfil for `for of` or `async/await` had to use exception to comply with the spec. As a result we were stuck using ES5.1 for a really long time (because we needed to support mobile browsers, which are (or were at this point, at least) a new kind of IE6.

I would love to do frontend web development but the current high-churn Javascript ecosystem makes me dizzy; this is probably a naive question but will it be possible to do web-development without integrating in the Javascript ecosystem using WebAssembly and Rust someday?

Eventually there will be direct binding between WebAssembly and web APIs like that the DOM that will allow you to write performant web apps that circumvent JS entirely. There are already tools that https://webassembly.studio/ that making writing wasm-based apps a reality, albeit still with a binding layer that goes through JS.

However, such applications will still have the same constraints that drive the current JS ecosystem. As such, there's little reason to believe that frameworks like React, Angular, Vue.js, etc. won't have their wasm-based equivalents. And, if anything, I except more churn for quite a few years, as people use the freedom provided by wasm to build a new generation of frameworks in completely different languages. We may look back on the current era of web development as a relatively stable one compared to what's to come.

So if the current churn is what turns you off web development, I wouldn't bet on wasm being a salve.

Another (non-Rust) but still interesting attempt towards this is being done by Microsoft:

https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-start...

In their case they compile a small enough subset of the .NET runtime to WebAssembly, and they got some JS to do the interop (I imagine till that glorious day of freedom comes). It's amazing what they've got working so far honestly.

Oh wow, I didn't realize that wasm did not currently have any direct bindings to the DOM. How does it interact with the page then? I saw a demo where they ported UE4 - how does something like that work without DOM access?

It calls to JavaScript which manipulates the DOM for it.

There already is, see https://github.com/DenisKolodin/yew for example.

The "put Rust in your JS" workflow is the first one the working group is focusing on; once that's awesome, other ones will get some work as well.

Maybe, but this post is to tell you that such use cases are explicitly not the focus of Rust and WebAssembly working group.

Actually, if you addopt a mindset where you don't care about the ecosystem as much, you don't need to wait for rust-wasm to mature.

For example, a friend of mine just shipped a web-app for a client, that wanted something to help them organize local chemists conference between few universities. He wrote it in Elixir. Didn't actually use Javascript, because it doesn't need to be a single-page-app, right? :) Few froms, nice theme. Ok, maybe there was few lines of jquery, where absolutely necessary.

I remember once using Vaadin, just because I already know Java and didn't really care that nobody uses Vaadin anymore :D

Or, if you don't actually have client to solve a problem for, but want to try out a cool tech, I would suggest playing around with PureScript. Inspired by Haskell, compiles to JS, has nice ecosystem and many of the libraries don't have JS dependencies. Or maybe Elm, if you want something simmilar, but more focused/lightweight? :-) Claudia Doppioslash has a nice overview of both: https://www.youtube.com/watch?v=9kGoaUqcq4A

You can already do frontend development pretty well, by just relying on the technologies that have proven to be backward-compatible (for instance: the JavaScript language, HTML, CSS).

> I would love to do frontend web development but the current high-churn Javascript ecosystem makes me dizzy; this is probably a naive question but will it be possible to do web-development without integrating in the Javascript ecosystem using WebAssembly and Rust someday?

there are 2 different things, there is the DOM/Web API and the language, Javascript.

Nobody forces you to use anything from the JavaScript ecosystem, not even node.js, in order to use the DOM. This complexity is totally unnecessary.

I personally settled on Typescript, nothing more. Its compiler gives me Javascript WITH static typing, and converts my code to a version of JavaScript that will run on the majority of the browsers, even internet explorer 8/9 or old Android browsers. No need for React,Angular, Webpack, Babel and all that stuff...

As I'm not writing games or photoshop in the browser I see no need to use Rust,C,C++ and the SDL just to write web apps.

IMHO some people ultimately miss the true usefulness and use case for WASM: making existing C,C++,... libraries available to Javascript developers, not replacing JS with language X or Z.

We agree that that use-case is useful, and that’s exactly why we’re focusing on it. Augment, not replace.

I'm excited at the prospect of compiling TypeScript directly to wasm in the future (see for example [0]). Someday you may be able to recompile that TS project and get substantial gains for free.

[0] https://github.com/AssemblyScript/assemblyscript

> I would love to do frontend web development but the current high-churn Javascript ecosystem makes me dizzy

Learn the actual web: HTML, CSS, and JavaScript are stable and don’t require any tooling in modern browsers. It’s pretty civilized these days with native support for ES6 classes, modules, arrow functions, data structures, spread & destructuring, fetch, async/await, etc. and things like CSS Grid for layout (head over to https://developer.mozilla.org for anything unfamiliar in that list). Support for non-current browsers can wait, hopefully until someone is paying you, and that’s a great time to learn about polyfills and transpilers.

The nice part about that is that it also plays great with WASM: you can write clean JS and call back and forth easily rather than trying to get dreadnaught-weight frameworks to work differently. I’m enjoying that right now since I see substantial gains swapping Rust-based hashing code to replace pure-JS alternatives.

You can also just write plain, vanilla javascript and make a working web app. I have one, no npm is involved! It is nice.

> publish Rust code compiled to WASM on NPM

leftpad-rs.js? :)

Assuming you get better performance and less size something like lodash-rs would have been nice.

Reply on news.ycombinator.com