So this is an issue with WASM/JS interop, not with Rust per se?
We rewrote our Rust WASM parser in TypeScript and it got faster
61–70 of 239 posts
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#62Am I mistaken or isn’t TypeScript just Golang under the hood these days?
Hmm, there's an in-progress rewrite of the TypeScript compiler in Go; is that what you mean? I don't think that's actually out yet, and more importantly, it doesn't change anything at runtime -- your code still runs in a JS engine (V8, JSC etc).
npm i -D @typescript/native-preview
You can use it today.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#63Something not unlike this happened to me when moving some batch processing code from C++ to Python 1.4 (this was 1997). The batch started finishing about 10x faster. We refused to believe it at first and started looking to make sure the work was actually being done. It was. The port had been done in a weekend just to see if we could use Python in production. The C++ code had taken a few months to write. The port was…
> After identifying the small misbehaving function, we had to study the C++ code pretty hard to even understand what the problem was. I don't remember the exact nature of the bug, but I do remember thinking that particular type of bug would be hard to express in Python, and that's exactly why it was accidentally fixed. Pure speculation, but I would guess this has something to do with a copy constructor getting invoke…
Given the context, I'm thinking bad cache keys resulting in spurious cache misses, where the keys are built in some low-level way. Cache misses almost certainly have a bigger asymptotic impact than extra copies, unless that copy constructor is really heavy.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#64Something not unlike this happened to me when moving some batch processing code from C++ to Python 1.4 (this was 1997). The batch started finishing about 10x faster. We refused to believe it at first and started looking to make sure the work was actually being done. It was. The port had been done in a weekend just to see if we could use Python in production. The C++ code had taken a few months to write. The port was…
[dead]
I don't think the better software part is playing out
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#65Earlier quoted context omitted.
> After identifying the small misbehaving function, we had to study the C++ code pretty hard to even understand what the problem was. I don't remember the exact nature of the bug, but I do remember thinking that particular type of bug would be hard to express in Python, and that's exactly why it was accidentally fixed. Pure speculation, but I would guess this has something to do with a copy constructor getting invoke…
Given the context, I'm thinking bad cache keys resulting in spurious cache misses, where the keys are built in some low-level way. Cache misses almost certainly have a bigger asymptotic impact than extra copies, unless that copy constructor is really heavy.
I'm just remembering a performance issue I heard of eons ago where a sorting function comparison callback inadvertently allocated memory. It made sorting very slow. Someone said in a meeting that sorting was slow, and we all had a laugh about "shouldn't have used the bubble sort!" But it was the key comparison doing something stupid.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#66[flagged]
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#67Earlier quoted context omitted.
Its a pretty well-supported claim. uv skips doing a number of things that generate file I/O. File I/O is far more costly than the difference in raw computation. pip can't drop those for compatibility reasons. https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html
I don't think the article you linked supports the claim that none of UV performance improvements are related to using rust over python at all. In fact it directly states the exact opposite. They have an entire section dedicated to why using Rust has direct performance advantages for UV.
What it says is this:
> uv is fast because of what it doesn’t do, not because of what language it’s written in. The standards work of PEP 518, 517, 621, and 658 made fast package management possible. Dropping eggs, pip.conf, and permissive parsing made it achievable. Rust makes it a bit faster still.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#68Earlier quoted context omitted.
I don't think the article you linked supports the claim that none of UV performance improvements are related to using rust over python at all. In fact it directly states the exact opposite. They have an entire section dedicated to why using Rust has direct performance advantages for UV.
What it says is this: > uv is fast because of what it doesn’t do, not because of what language it’s written in. The standards work of PEP 518, 517, 621, and 658 made fast package management possible. Dropping eggs, pip.conf, and permissive parsing made it achievable. Rust makes it a bit faster still.
Yes exactly! That quote directly disproves that all of the improvements UV has over competitors is because of algos, not because of rust.
So the claim is not well supported at all by the article as you stated, in fact the claim is literally disproven by the article.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#69Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#70Earlier quoted context omitted.
[dead]
I don't think the better software part is playing out
you're thinking of the programs in low-level langs that survived their higher-level-lang competitors; if you plot the programs on your machine by age, how does the low quartile compare on reliability between programs written in each group