Now they just need a third party who's never seen the original to rewrite their TypeScript solution in Rust for even more gains.
replyIndeed! But only after a year or so of using it in production, so that the drawbacks would be discovered.
replyYou're generally right - rewrites let you improve the code - but they do have an actual reason the new language was better: avoiding copies on the boundary.
replyThey say they measured that cost, and it was most of the runtime in the old version (though they don't give exact numbers). That cost does not exist at all in the new version, simply because of the language.
It's doing copies and (de)serialization on both sides into native data types.
replyIf they used raw byte structures, implemented the caching improvements on the wasm side, the copies might not be as bad.
But they still have an issue with multi-language stack: complexity also has a cost.
Python/C combo does not have this issue because you can work with Python types natively in C, but otherwise, this is a cross-language conversion issue, and not a Rust issue at all.
One of the authors here. While that’s generally true, in this case it wasn’t time that helped us learn what worked. It was a nagging sense that the architecture wasn’t right, just days before launch, along with heavy instrumentation to test our assumptions.
replyTruth. You can see improvement, even rewriting code in the same language.
replyI have been saying this for a while now (thought it was obvious), and often I get downvoted when I point this out.
replyI think that they were honest about that to a degree, they pointed out that one source of the speed up was caused by the python fixing a big they hadn't noticed in the C++
replyEdit: fixed phone typos