Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We rewrote our Rust WASM parser in TypeScript and it got faster

openui.com

Post reply on HN
Print view View original

81–90 of 239 posts

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#81

Post by Aurornis »

DaleBiagio wrote: post #48
rented_mule wrote: post #34

Something 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]

This comment comes from a bot account. One of the more clever ones I’ve seen that avoids some of the usual tells, but the comment history taken together exposes it.

I hit the flag button on the comment and suggest others do too.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#82

Post by Defletter »

crubier wrote: post #44
estebank wrote: post #18

Earlier 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.

Would you be willing to give an example of this?

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#83

Post by horacemorace »

I’m more of a dabbler dev/script guy than a dev but Every. single. thing I ever write in javascript ends up being incredibly fast. It forces me to think in callbacks and events and promises. Python and C (or async!) seem easy and sorta lazy in comparison.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#84

Post by kyralis »

rowanG077 wrote: post #68
jeremyjh wrote: post #67

Earlier 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.

This is either an overly pedantic take or a disingenuous one. The very first line that the parent quoted is

> uv is fast because of what it doesn’t do, not because of what language it’s written in.

The fact that the language had a small effect ("a bit") does not invalidate the statement that algorithmic improvements are the reason for the relative speed. In fact, there's no reason to believe that rust without the algorithmic version would be notably faster at all. Sure, "all" is an exaggeration, but the point made still stands in the form that most readers would understand it: algorithmic improvements are the important difference between the systems.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#85

Post by rowanG077 »

kyralis wrote: post #84
rowanG077 wrote: post #68

Earlier 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.

This is either an overly pedantic take or a disingenuous one. The very first line that the parent quoted is > uv is fast because of what it doesn’t do, not because of what language it’s written in. The fact that the language had a small effect ("a bit") does not invalidate the statement that algorithmic improvements are the reason for the relative speed. In fact, there's no reason to believe that rust without the alg…

I think we might be talking past each other a bit.

The specific claim I was responding to was that all of uv’s performance improvements come from algorithms rather than the language. My point was just that this is a stronger claim than what the article supports, the article itself says Rust contributes “a bit” to the speed, so it’s not purely algorithmic.

I do agree with the broader point that algorithmic and architectural choices are the main reason uv is fast, and I tried to acknowledge that, apparently unsuccessfully, in my very my first comment (“I don't doubt that a lot of uv's benefits are algo. But everything?”).

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#86

Post by ameixaseca »

rented_mule wrote: post #34

Something 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…

My experience is the exact opposite.

This was particularly true for one of the projects I've worked with in the past, where Python was chosen as the main language for a monitoring service.

In short, it proved itself to be a disaster: just the Python process collecting and parsing the metrics of all programs consumed 30-40% of the processing power of the lower end boxes.

In the end, the project went ahead for a while more, and we had to do all sorts of mitigations to get the performance impact to be less of an issue.

We did consider replacing it all by a few open source tools written in C and some glue code, the initial prototype used few MBs instead of dozens (or even hundreds) of MBs of memory, while barely registering any CPU load, but in the end it was deemed a waste of time when the whole project was terminated.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#87

Post by sroussey »

fn-mote wrote: post #29
sroussey wrote: post #9

Earlier quoted context omitted.

Yeah, though the n^2 is overstating things. One thing I noticed was that they time each call and then use a median. Sigh. In a browser. :/ With timing attack defenses build into the JS engine.

For those of us not in the know, what are we expecting the results of the defenses to be here?

Jitter. It make precise timings unreliable. Time the entire time of 1000 runs and divide by 1000 instead of starting and stopping 1000 timers.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#88

Post by EdwardDiego »

estebank wrote: post #18
socalgal2 wrote: post #14

Earlier quoted context omitted.

same for uv but no one takes that message. They just think "rust rulez!" and ignore that all of uv's benefits are algo, not lang.

Some architectures are made easier by the choice of implementation language.

UV also has the distinct advantage in dependency resolution that it didn't have to implement the backwards compatible stuff Pip does, I think Astral blogged on it. If I can find it, I'll edit the link in.

edit wasn't Astral, but here's the blog post I was thinking of. https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

That said, your point is very much correct, if you watch or read the Jane Street tech talk Astral gave, you can see how they really leveraged Rust for performance like turning Python version identifiers into u64s.

Re: We rewrote our Rust WASM parser in TypeScript and it got faster

#89

Post by jesse__ »

simonbw wrote: post #74

Yeah 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…

This should be the top comment
Post reply on HN