[flagged]
We rewrote our Rust WASM parser in TypeScript and it got faster
71–80 of 239 posts
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#72Earlier quoted context omitted.
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.
You are right. 99% is not 100%.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#73I tried a similar experiment recently w/ FFT transform for wav files in the browser and javascript was faster than wasm. It was mostly vibe coded Rust to wasm but FFT is a well-known algorithm so I don't think there were any low hanging performance improvements left to pick.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#74Yeah if you're serializing and deserializing data across the JS-WASM boundary (or actually between web workers in general whether they're WASM or not) the data marshaling costs can add up. There is a way of sharing memory across the boundary though without any marshaling: TypedArrays and SharedArrayBuffers. TypedArrays let you transfer ownership of the underlying memory from one worker (or the main thread) to another without any copying. SharedArrayBuffers allow multiple workers to read and write to the same contiguous chunk of memory. The downside is that you lose all the niceties of any JavaScript types and you're basically stuck working with raw bytes.
You still do get some latency from the event loop, because postMessage gets queued as a MacroTask, which is probably on the order of 10μs. But this is the price you have to pay if you want to run some code in a non-blocking way.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#75Something 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]
Until at some point in a language like python all the things that allowed you write software faster start to slow you down like the lack of static typing and typing errors and spending time figuring out whether foo method works with ducks or quacks or foovars or whether the latest refactoring actually silently broke it because now you need bazzes instead of ducks. Yeah.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#76Something 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]
Thanks, Programming History Facts Bot
I was not actually sure this one was a bot, despite LLM-isms and, sadly, being new. But you can look at the comment history and see.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#77Earlier quoted context omitted.
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.
You are right. 99% is not 100%.
I don't think the article has substantive numbers. You'd have to re-implement UV in python to do that. I don't think anyone did that. It would be interesting at least to see how much UV spends in syscalls vs PIP and make a relative estimate based on that.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#78I heard a lot of similar stories in the past when I started using Python 20+ years ago. A number of people claimed their solutions got faster when develop in Python, mainly because Python make it easier to quickly pivot to experiment with various alternative methods, hence finally yield at more efficient outcome at the end.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#79The real win here isn't TS over Rust, it's the O(N²) -> O(N) streaming fix via statement-level caching. That's a 3.3x improvement on its own, independent of language choice. The WASM boundary elimination is 2-4x, but the algorithmic fix is what actually matters for user-perceived latency during streaming. Title undersells the more interesting engineering imo.
You’re not wrong, but that win would not get as many views. It’s not clickbaity enough
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#80Earlier quoted context omitted.
Some architectures are made easier by the choice of implementation language.
In my experience Rust typically makes it a little bit harder to write the most efficient algo actually.
That’s usually ok bc in most code your N is small and compiler optimizations dominate.