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

221–230 of 239 posts

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

#221

Post by anthk »

eru wrote: post #212
anthk wrote: post #157

Earlier quoted context omitted.

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.

> Flakey internet connection: most of current 'soy devs' would be useless. We used to make the same jokes about Googling Stackoverflow since before many users on this site were born.

And it's partially true. Offline documentation should be mandatory everywhere. Networks can be degraded tomorrow in the current 2nd Cold War we are living. And, yes, the states and goverments have private backbones for the military/academia/healthcare and so on, but the rest it's screwed.

When the blackout the only protocols which worked fine where IRC, Gopher and Gemini. I could resort to using IRC->Bitlbee to chat against different people of the world, read news and proxy web sites over Gemini (the proto, not the shitty AI). But, for the rest, the average folk? half an our to fetch a non-working page.

That with a newspaper, go figure with the rest. And today tons of projects use sites with tons of JS and unnecesary trackers and data. In case of a small BGP attack, most projects done with LLM's will be damned. Because they won't even have experience on coding without LLM's. Without docs it's game over.

Also tons of languages pull dependencies. Linux distros with tons of DVD's can survive offline with Python, but good luck deploying NPM, Python and the rest projects to different OSes. If you are lucky you can resort to the bundled Go dependencies in Debian and cross compile, and the same with MinGW cross compiling against Windows with some Win32, SDL, DX support but that's it.

With QT Creator and MinGW, well, yes, you could build something reliable enough -being cross platform- and with Lazarus/Free Pascal, but forget about current projects downloading 20000 dependencies.

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

#222

Post by staticassertion »

tinco wrote: post #217
staticassertion wrote: post #207

Earlier quoted context omitted.

I think a missing piece here is that you think that Rust won't download a file faster than Python but it absolutely can. This seems to just be a misconception people have about IO, like "download a file" is a thing that exists wholly outside of your process.

I know it can, but it can't download it faster than the network card can write it into its buffers. That's the part I would count as the 50ms that both can't improve upon.

Of course. But why would that matter if Python can't get there to begin with? You're not going to hit NIC bottlenecks with Python, not without a ton of work and tradeoffs at least.

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

#223

Post by measurablefunc »

wintermute4282 wrote: post #163
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

It was just an experiment in vibe coding. It's easy enough to try different architectures w/ AI coding but what I wanted to see was whether naive numeric calculations were faster w/ wasm or javascript & it turned out that javascript was faster so the performance trade-off between wasm & javascript is not as simple as between a high-level language like python & SIMD optimized C/assembly.

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

#224

Post by elcritch »

eru wrote: post #220
elcritch wrote: post #135

Earlier quoted context omitted.

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.

Could you ask the LLM to do a write-up on the process and post it? (Or you can write a blog post by hand. Like a caveman. ;)

I find writing by hand is the best. LLMs spit out such linked-in writing that I don’t even want to read it. ;)

But that would be a good blog post and I got some travel coming up. But honestly it was just “oh here’s a BLE python library, see if we can get it running”. I prefer Codex because it seems to do well for guiding the LLMs for complete engineering changes.

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

#225

Post by elcritch »

anthk wrote: post #221
eru wrote: post #212

Earlier quoted context omitted.

> Flakey internet connection: most of current 'soy devs' would be useless. We used to make the same jokes about Googling Stackoverflow since before many users on this site were born.

And it's partially true. Offline documentation should be mandatory everywhere. Networks can be degraded tomorrow in the current 2nd Cold War we are living. And, yes, the states and goverments have private backbones for the military/academia/healthcare and so on, but the rest it's screwed. When the blackout the only protocols which worked fine where IRC, Gopher and Gemini. I could resort to using IRC->Bitlbee to chat…

Heh, my preferred language is Nim which has good docs for the stdlib. It also does static binaries and runs on esp32 like a dream. I’m not worried about some internet downtime, but I also enjoy what I can guide LLMs to build for me.

The BLE battery syncing was a nice-to-have for an IoT prototype. Not something I wanted to spend hours digging through wireshark to figure out but fine for some LLM hacking.

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

#226

Post by [deleted] »

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.

[deleted]

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

#228

Post by eru »

anthk wrote: post #221
eru wrote: post #212

Earlier quoted context omitted.

> Flakey internet connection: most of current 'soy devs' would be useless. We used to make the same jokes about Googling Stackoverflow since before many users on this site were born.

And it's partially true. Offline documentation should be mandatory everywhere. Networks can be degraded tomorrow in the current 2nd Cold War we are living. And, yes, the states and goverments have private backbones for the military/academia/healthcare and so on, but the rest it's screwed. When the blackout the only protocols which worked fine where IRC, Gopher and Gemini. I could resort to using IRC->Bitlbee to chat…

> Offline documentation should be mandatory everywhere. Networks can be degraded tomorrow in the current 2nd Cold War we are living.

Eh? It's all about trade-offs. If our infrastructure is degraded enough that the internet goes down, I have more important things to do than work through a few more Jira tickets.

Especially since a lot of the work me and a lot of other folks are doing is delivered to customers via the internet anyway.

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

#229

Post by rented_mule »

WalterBright wrote: post #188
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 soon found out that we could make algorithmic improvements so much more quickly It's true that writing code in C doesn't automatically make it faster. For example, string manipulation. 0-terminated strings (the default in C) are, frankly, an abomination. String processing code is a tangle of strlen, strcpy, strncpy, strcat, all of which require repeated passes over the string looking for the 0. (Even worse, relo…

What an honor to have Walter Bright respond to my comment! I used Zortech C++ extensively in the late 1980s and early 1990s on OS/2 and Windows. That beautiful black and purple cube-shaped box sat prominently on my bookshelf for many years. Thanks Walter!

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

#230

Post by littlestymaar »

philipallstar wrote: post #193
littlestymaar wrote: post #136

Earlier quoted context omitted.

And this is why pretty much all commercial software is terrible and runs slower than the equivalent 20 years ago despite incredible advance in hardware.

For lots of software there wasn't an equivalent 20 years ago because there wasn't a language that would let developers explore semi-specified domains fast enough to create something useful. Unless it was visual basic, but we can't use that, because what would all the UX people be for?

Python itself is 30 years old. What are you talking about?

Almost every mainstream languages (except Go, Swift, Kotlin and Rust) are more than 30 years old, by the way.

Post reply on HN