Kudos to them for publicly owning their missteps and for changing their minds based on evidence.
I’m not an expert in either Rust or JS, but I do know that the language you use influences the design of your code. Not just because of the affordances of the language (“everything is a key/value map!” vs. “maps are one available tool but not the cheapest”) but because a closer-to-the-metal language keeps you more focused on performance.
Which is to say that taking an architecture designed in JS and porting it to Rust is likely to be suboptimal compared to designing in Rust. Again, not expert at these languages, but I have experienced the same effect with designing in Objective-C vs designing in C++.
Agreed, that was a fascinating read. They seem to have hit two lessons that I’ve also learned somewhat painfully:
Incremental migration from language X to language Y is unlikely to give massive performance wins. Your code will be structured around things that are fast in language X, so won’t be able to take advantage of things that may be significantly faster in language Y unless you significantly rearchitect things. Worse, they may take advantage of things that are moderately fast in language X but painfully slow in language Y, so you may need to do some more considerable rewriting anyway.
The is often no win from improving the performance of code written in a ‘slow’ language because people writing it know that the language is slow and try to restrict it to control plane operations. A Python program that’s driving an OpenMP numerics library or a JavaScript program that’s driving a pile of shader code may get a small speedup from a faster Python / JavaScript implementation but it’s not their bottleneck.
For my web app, I looked into replacing a JS-based blurhash implementation with a Rust-based one. I benchmarked it, and found that the JS one was just as fast after the 3rd iteration (presumably because of the JIT kicking in).
As said elsewhere, WASM is not magic performance pixie dust. It makes sense in certain cases, but benchmark before jumping to conclusions.
I have been playing with WASM and Rust for a few things. The motivation hasn’t been speed though It has been the ability to use a far superior typesystem. After all both wasm and javascript are interpreted. The primary benefit is being free to use something other than only javascript for browser based frontend development.
TypeScript also has a pretty nice type system. I was surprised at how comfortable it felt, coming from a C++ (and some Swift) background. The flow-based typing is especially handy.
When compared to Javascript, Typescript’s type system is a massive leap forward. I wholeheartedly endorse it’s usage by anyone.
However, compared to Rust, Typescript doesn’t come anywhere near giving me the same guarantees. Rust/WASM let’s me get an even more expressive type-system to model my software’s contracts with. It won’t always be the best choice but all else being equal a Rust type system beats TypeScript any day.
I prefer TypeScript’s types to Rust’s a lot of the time, but it often depends on the domain I’m in. For lower level things around managing resources Rust’s shines but for higher level modelling of app data I prefer TypeScript’s. What’s universal is that when I’m using one, at some point I miss a feature of the other :-)
Kudos to them for publicly owning their missteps and for changing their minds based on evidence.
I’m not an expert in either Rust or JS, but I do know that the language you use influences the design of your code. Not just because of the affordances of the language (“everything is a key/value map!” vs. “maps are one available tool but not the cheapest”) but because a closer-to-the-metal language keeps you more focused on performance.
Which is to say that taking an architecture designed in JS and porting it to Rust is likely to be suboptimal compared to designing in Rust. Again, not expert at these languages, but I have experienced the same effect with designing in Objective-C vs designing in C++.
Agreed, that was a fascinating read. They seem to have hit two lessons that I’ve also learned somewhat painfully:
For my web app, I looked into replacing a JS-based blurhash implementation with a Rust-based one. I benchmarked it, and found that the JS one was just as fast after the 3rd iteration (presumably because of the JIT kicking in).
As said elsewhere, WASM is not magic performance pixie dust. It makes sense in certain cases, but benchmark before jumping to conclusions.
I have been playing with WASM and Rust for a few things. The motivation hasn’t been speed though It has been the ability to use a far superior typesystem. After all both wasm and javascript are interpreted. The primary benefit is being free to use something other than only javascript for browser based frontend development.
TypeScript also has a pretty nice type system. I was surprised at how comfortable it felt, coming from a C++ (and some Swift) background. The flow-based typing is especially handy.
When compared to Javascript, Typescript’s type system is a massive leap forward. I wholeheartedly endorse it’s usage by anyone.
However, compared to Rust, Typescript doesn’t come anywhere near giving me the same guarantees. Rust/WASM let’s me get an even more expressive type-system to model my software’s contracts with. It won’t always be the best choice but all else being equal a Rust type system beats TypeScript any day.
I prefer TypeScript’s types to Rust’s a lot of the time, but it often depends on the domain I’m in. For lower level things around managing resources Rust’s shines but for higher level modelling of app data I prefer TypeScript’s. What’s universal is that when I’m using one, at some point I miss a feature of the other :-)
There’s also PureScript and Elm, as well as some other very young options for browser languages that have nice type systems.
I never posted it as a blog, but I ran into something similar a few years ago when trying to optimize typescript code into wasm. Four-post thread here: https://mastodon.technology/@robey/104635185018008699