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

161–170 of 239 posts

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

#161

Post by naasking »

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…

> just the Python process collecting and parsing the metrics of all programs consumed 30-40% of the processing power of the lower end boxes.

Just write the parsing loop in something faster like C or Rust, instead of the whole thing.

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

#162

Post by staticassertion »

tinco wrote: post #119
staticassertion wrote: post #116

Earlier quoted context omitted.

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.

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

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.

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

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

#163

Post by wintermute4282 »

measurablefunc wrote: post #73

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

It looks like FFTW3 is working on wasm support: https://github.com/FFTW/fftw3/issues/293

You could also try pretty fast fft: https://github.com/JorenSix/pffft.wasm

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

#164

Post by nickserv »

Aeolun wrote: post #143
wiseowise wrote: post #113

Earlier quoted context omitted.

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

You can use Go and get the best of both worlds.

One of the slowest, most ineficient code bases I've ever worked on was in Go.

The mentality was "the language is fast, so as long as it compiles we're good"... Yeah that worked out about as well as you'd expect.

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

#165

Post by rabisg »

aquariusDue wrote: post #142
rabisg wrote: post #105

Earlier quoted context omitted.

Its the library that bridges the gap between LLMs and live UI. Best example would be to imagine you want to build interactive charts within your AI agent (like Claude) The most obvious approach would be to let LLMs generate code and render it but that introduces problems like safety, UI consistency and speed. OpenUI solves those problems and provides a safe, consistent and token optimized runtime for the LLMs to rend…

Is it kinda similar to the new GenUI SDK for Flutter in that sense? https://docs.flutter.dev/ai/genui

Haven't looked in depth but yes it feels like they are solving the same problem.

This is an alternative to json-render by Vercel or A2UI by Google which I'm guessing the flutter implementation is based on

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

#167

Post by 9rx »

rabisg wrote: post #103
tda wrote: post #100

Earlier quoted context omitted.

Ome advantage of python is that it is so slow that if you choose the wrong algorithm or data structure that soon gets obvious. And for complicated stuff this is exactly where I find the LLMs struggle. So I make a first version in Python, and only when I am happy with the results and the speed feels reasonable compared to the problem complexity, I ask Claude Code to port the critical parts to Rust.

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 finally be what breaks the JS camel's back. Although browser dominance still makes that unlikely.

> Very few people will then take the pain of optimizing it

Today's LLMs rarely take the initiative to write benchmarks, but if you ask it will and then will iterate on optimizing using the benchmark results as feedback. It works fairly well. There is a conceivable near future where LLMs or LLM tools will start doing this automatically.

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

#168

Post by rabisg »

bluelightning2k wrote: post #159

Great write up. It feels like craft in the age of slop. Not sold about the fundamental idea of OpenUI though. XML is a great fit for DSLs and UI snippets.

We tried all formats - XML, json, jsonl, even toon - before deciding that we need to invest in OpenUI Lang

The primary motivation was speed and schema cohesion. We were running a JSON based format, Thesys C1, in production for a year before we realized we cannot add features fast enough because we were fighting the LLMs at multiple levels. It's probably too much to write in a comment but we'd like to write about the motivation and all the things we tried ona a separate blog soon

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

#169

Post by mirsadm »

eru wrote: post #130
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

The LLMs are pretty good at optimising. Not because they are brilliant, but because they are pretty good at throwing pretty much all known techniques at a problem. And they also don't tire of profiling and running experiments.

Not in my experience. They're pretty good at getting average performance which is often better than most programmers seem to be willing to aim for.
Post reply on HN