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

111–120 of 239 posts

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

#111

Post by staticassertion »

harpiaharpyja wrote: post #110
staticassertion wrote: post #96

Earlier quoted context omitted.

It doesn't come off as unintuitive by my read. They had a bug that led to a massive performance regression. Rewriting the code didn't have that bug so it led to a performance improvement. They found that they had fewer bugs in Python so they continued with it.

I think a lot of people (especially those who are only peripherally involved in development, like management) don't really consider performance regressions at all when thinking about how to get software to go faster. Meanwhile my experience has been that whenever there has been a performance issue severe enough to actually matter, it's often been the result of some kind of performance bug, not so much language, runti…

My experience has been that performance bugs show up in lots of places and I'm very lucky when it's just a bug. The far more painful performance issues are language and runtime limitations.

But, of course, profiling is always step one.

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

#112

Post by tinco »

staticassertion wrote: post #93
jeremyjh wrote: post #51

Earlier 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

Do you actually believe that UV would be as fast if it were written in Python?

It would come pretty close, probably close enough that you wouldn't be able to tell the difference on 90% of projects.

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

#113

Post by wiseowise »

ameixaseca wrote: post #86
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…

> but in the end it was deemed a waste of time when the whole project was terminated.

The main lesson of the story. Just pick Python and move fast, kids. It doesn’t matter how fast your software is if nobody uses it.

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

#114

Post by staticassertion »

tinco wrote: post #112
staticassertion wrote: post #93

Earlier quoted context omitted.

Do you actually believe that UV would be as fast if it were written in Python?

It would come pretty close, probably close enough that you wouldn't be able to tell the difference on 90% of projects.

Vague. What's pretty close? I mean, even for IO bound tasks you can pretty quickly validate that the performance between languages is not close at all - 10 to 100x difference.

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

#115

Post by tinco »

staticassertion wrote: post #114
tinco wrote: post #112

Earlier quoted context omitted.

It would come pretty close, probably close enough that you wouldn't be able to tell the difference on 90% of projects.

Vague. What's pretty close? I mean, even for IO bound tasks you can pretty quickly validate that the performance between languages is not close at all - 10 to 100x difference.

Sure, within 100ms. Who cares what the performance multiples are?

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

#116

Post by staticassertion »

tinco wrote: post #115
staticassertion wrote: post #114

Earlier quoted context omitted.

Vague. What's pretty close? I mean, even for IO bound tasks you can pretty quickly validate that the performance between languages is not close at all - 10 to 100x difference.

Sure, within 100ms. Who cares what the performance multiples are?

That literally makes no sense. 100ms... out of what? Is it 1ms vs 100ms? 100000ms vs 100100ms?

Anyway, dubious claim since a Python interpreter will take 10s of milliseconds just to print out its version.

Do you have any evidence? I can point at techempower benchmarks showing IO bound tasks are still 10-100x faster in native languages vs Python/JS.

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

#117

Post by stephantul »

wiseowise wrote: post #113
ameixaseca wrote: post #86

Earlier quoted context omitted.

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…

> but in the end it was deemed a waste of time when the whole project was terminated. The main lesson of the story. Just pick Python and move fast, kids. It doesn’t matter how fast your software is if nobody uses it.

This is it. Getting something on the table for stakeholders to look at trumps anything else.

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

#118

Post by lukeweston1234 »

Defletter wrote: post #82
crubier wrote: post #44

Earlier quoted context omitted.

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?

Not OP, but one example where it is a bit harder to do something in Rust that in C, C++, Zig, etc. is mutability on disjoint slices of an array. Rust offers a few utilities, like chunks_by, split_at, etc. but for certain data structures and algorithms it can be a bit annoying.

It's also worth noting that unsafe Rust != C, and you are still battling these rules. With enough experience you gain an understanding of these patterns and it goes away, and you also have these realy solid tools like Miri for finding undefined behavior, but it can be a bit of a hastle.

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

#119

Post by tinco »

staticassertion wrote: post #116
tinco wrote: post #115

Earlier quoted context omitted.

Sure, within 100ms. Who cares what the performance multiples are?

That literally makes no sense. 100ms... out of what? Is it 1ms vs 100ms? 100000ms vs 100100ms? Anyway, dubious claim since a Python interpreter will take 10s of milliseconds just to print out its version. Do you have any evidence? I can point at techempower benchmarks showing IO bound tasks are still 10-100x faster in native languages vs Python/JS.

I'm saying that the Rust might execute in 50ms and the Python in 150ms. You are the one not making sense, we are talking about application performance, why are you not measuring that in milliseconds.

That is assuming Rust is 100x faster than Python btw, 49ms of I/O, 1ms of Rust, 100ms of Python.

Post reply on HN