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

171–180 of 239 posts

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

#171

Post by jeremyjh »

staticassertion wrote: post #162
tinco wrote: post #119

Earlier quoted context omitted.

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.

> I'm saying that the Rust might execute in 50ms and the Python in 150ms. Okay, so the Rust code would be 3x as fast. Feels arbitrary, but sure. > You are the one not making sense, we are talking about application performance, why are you not measuring that in milliseconds. I explained why your post made no sense already... > That is assuming Rust is 100x faster than Python btw, 49ms of I/O, 1ms of Rust, 100ms of Pyt…

> Different languages will perform differently on IO work,

IO is executed by kernel, file system or network drivers. IO performance is not dependent at all on which language makes the syscalls.

> The thing we can agree with is this - no, uv would not be as fast if it were written in Python.

In this thread, we are talking about the speed of uv in terms of user experience - how long a person waits for command line operations to complete. Things that pip takes multiple seconds to do, uv will do in dozens of milliseconds. If uv were written in python, it would take dozens of ms + a few dozens more, which means absolutely fuck all nothing in the context of the thousands of milliseconds saved over pip.

Its possible a user might perceive a slight difference in larger projects, but if pip had been uv-but-in-python, the uv-in-rust project would never have been started in the first place because no one would have bothered switching.

> This conversation has become nonsensical.

Agreed. No one in this thread is disputing that Rust code is faster than Python, only that in this case it is completely insignificant in the face of all the useless file and network I/O that pip is doing, and uv is not.

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

#172

Post by coldtea »

wolvesechoes wrote: post #154
coldtea wrote: post #150

Earlier quoted context omitted.

The opposite: the more you rely on abstractions the more you miss the lower level optimization opportunities and loose understanding of algorithms and hardware.

> of algorithms Yes, sprinkling your code logic with malloc, .clone() or lifetime annotations on the other hand brings algorithmic enlightenment.

Dealing and having to think about the cost of malloc, clone() and lifetimes, brings algorithmic enlightenment more than working on an high abstraction ivory tower where things "magically happen".

Is your argument that the average Python or Typescript dev gets to think and care more about algorithms than the average C/C++/Rust dev?

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

#174

Post by Traubenfuchs »

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…

He struggled with the algorithms, you struggled with the runtime.

You are not the same.

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

#175

Post by tinco »

staticassertion wrote: post #162
tinco wrote: post #119

Earlier quoted context omitted.

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.

> I'm saying that the Rust might execute in 50ms and the Python in 150ms. Okay, so the Rust code would be 3x as fast. Feels arbitrary, but sure. > You are the one not making sense, we are talking about application performance, why are you not measuring that in milliseconds. I explained why your post made no sense already... > That is assuming Rust is 100x faster than Python btw, 49ms of I/O, 1ms of Rust, 100ms of Pyt…

> That's not how anything works. Different languages will perform differently on IO work, different runtimes will degrade under IO differently, etc. That's why even basic echo HTTP servers perform radically differently in Python vs Rust.

> This isn't how computers work and it's not even how math works.

What are you disagreeing with? There's some baseline amount of I/O that the kernel does for you, that's what I'm assuming is 50ms, and everything else like runtime degrading is overhead due to the language/platform choice. I'm saying Rust is upwards of 100x faster in that regard thanks to its zero cost abstraction philosophy. You can't just include the I/O baseline in a claim about Rust's performance advantage. You'll be really disappointed when Rust doesn't download your files 100x as fast as the Python file downloader.

Anyway, I'm sorry I provoked your antagonism with my terse messages, I wasn't trying to be blase. I believe uv is the sort of tool that wouldn't suffer much from the downsides of Python and that in most situations the reduced runtime overhead of Rust would have a negligible impact on the user experience. I'm not arguing that they shouldn't build uv in Rust. Most situations is not all situations, and when a tool is used so widely you'll hit all edge cases, from the point where the 10s of milliseconds of startup time matters to the point where Pythons I/O overhead matters at scale.

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

#178

Post by catlifeonmars »

lukeweston1234 wrote: post #118
Defletter wrote: post #82

Earlier quoted context omitted.

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

Has no one written a python! macro for this use case?

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

#180

Post by rabisg »

9rx wrote: post #167
rabisg wrote: post #103

Earlier quoted context omitted.

The last part is really interesting. It feels like the whole world will soon become Python/JS because thats what LLMs are good at. Very few people will then take the pain of optimizing it

> JS because thats what LLMs are good at. That has not been my experience. JS/TS requires the most hand-holding, by far. LLMs are no doubt assumed to be good at JS due to the sheer amount of training data, but a lot of those inputs are of really poor quality, and even among the high quality inputs there isn't a whole lot of consistency in how they are written. That seems to trip up the LLMs. If anything, LLMs might f…

My experience is from trying to get the React Native example to work with OpenUI. Felt Sonnet/Opus was much better at figuring out whats wrong with the current React implementation and fixing it than it was with React Native

But yes I see what you mean and I think people are trying to solve it with skills and harnesses at the application layer but its not there yet

Post reply on HN