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

151–160 of 239 posts

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

#151

Post by coldtea »

socalgal2 wrote: post #14
blundergoat wrote: post #2

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

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.

Just the fact that I can install a single binary is 10x better than an equally fast Python implementation.

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

#153

Post by pjmlp »

coldtea wrote: post #149
pjmlp wrote: post #148

This is why, when a programming language already has tooling for compilers, being it ahead of time, or dynamic, it pays off to first go around validating algorithms and data structures before a full rewrite. Additionally even after those options are exhausted, only a key parts might need a rewrite, not the whole thing. However, I wonder how many care about actually learning about algorithms, data structures and mecha…

> However, I wonder how many care about actually learning about algorithms, data structures and mechanical sympathy in the age of Electron apps. Never mind the age of Electron apps, even fewer care about those in the age of agents.

Agreed, however I would assert that in the age of agents, programming languages will become irrelevant to most, other those lucky enough druids to write AI runtime stack, at the AI overlords.

And those will still care about CS.

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

#154

Post by wolvesechoes »

coldtea wrote: post #150
wolvesechoes wrote: post #138

Earlier quoted context omitted.

> The real win here isn't TS over Rust Kinda is. We came up with abstractions to help reason about what really matters. The more you need to deal with auxillary stuff (allocations, lifetimes), more likely you will miss the big issue.

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.

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

#155

Post by branko_d »

asveikau wrote: post #58
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…

> After identifying the small misbehaving function, we had to study the C++ code pretty hard to even understand what the problem was. I don't remember the exact nature of the bug, but I do remember thinking that particular type of bug would be hard to express in Python, and that's exactly why it was accidentally fixed. Pure speculation, but I would guess this has something to do with a copy constructor getting invoke…

My guess would be bad hashing, resulting in too many collisions.

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

#157

Post by anthk »

elcritch wrote: post #135
eru wrote: post #130

Earlier quoted context omitted.

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 just profiling, but decoding protocols too. Recently I tried Codex/GPT5 with updating a bluetooth library for batteries and it was able to start capturing bluetooth packets and comparing them with the libraries other models. It was indefatigable. I didn't even know if was so easy to capture BLE packets.

Wireshark would do that. But you need to understand low level tools because in case on some BGP attack you all LLM developers will be fired in the spot.

Flakey internet connection: most of current 'soy devs' would be useless. Even more with boosted up chatbots.

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

#158

Post by nubg »

shevy-java wrote: post #121
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…

> We immediately started moving the rest of our back end to Python. Most things were slower, but not by much because most of our back end was i/o bound. Would be kind of cool if e. g. python or ruby could be as fast as C or C++. I wonder if this could be possible, assuming we could modify both to achieve that as outcome. But without having a language that would be like C or C++. Right now there is a strange divide be…

@dang this is an ai slop account, check his other comments

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

#160

Post by twoodfin »

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.

Are you kidding? To the extent this was “crafted” it was by an LLM from somebody’s notes in a prompt.

The other day, someone linked back to this 2018 post on finding a cache coherency bug in the Xbox 360 CPU:

https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-d...

So much more genuinely engaging than any of the AI-“enhanced” sloppy, confused, trite writing that gets to the front page here daily because it’s been hyper-optimized for upvotes.

Post reply on HN