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

121–130 of 239 posts

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

#121

Post by shevy-java »

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 between "scripting" languages and compiled ones.

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

#122

Post by shevy-java »

stephantul wrote: post #117
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.

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

[flagged]

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

#123

Post by peter_retief »

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…

I suspect that you used highly optimized algorithms written for python, like the vector algorithms in numpy? You will struggle to write better code, at least I would.

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

#125

Post by masklinn »

peter_retief wrote: post #123
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…

I suspect that you used highly optimized algorithms written for python, like the vector algorithms in numpy? You will struggle to write better code, at least I would.

Python 1.4 would be mid-late 90s long before numpy and vector algorithms would have been available.

I suspect it’s more likely to be something like passing std::string by value not realising that would copy the string every time, especially with the statement that the mistake would be hard to express in Python.

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

#127

Post by Dwedit »

JS and WASM share the main arraybuffer. It's just very not-javascript-like to try to use an arraybuffer heap, because then you don't have strings or objects, just index,size pairs into that arraybuffer.

Anyway, Javascript is no stranger to breaking changes. Compare Chromium 47 to today. Just add actual integers as another breaking change, then WASM becomes almost unnecessary.

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

#128

Post by quotemstr »

bulbar wrote: post #124

Is this an outlier or has Rust started to be part of the establishment and being 'old' so that people want to share their "moving away from Rust" stories? I didn't mind reading articles that are not about how Rust is great in theory (and maybe practice).

There's a certain segment of the industry that's always chasing the newest thing. Many of them like Zig for some ghastly reason.

That said, Rust does have real problems. Manual memory management sucks. People think GC is expensive? Well, keep in mind malloc() and free() take global locks! People just have totally bogus mental models of what drives performance. These models lead them to technical nonsense.

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

#129

Post by sincerely »

envguard wrote: post #47
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…

[flagged]

AI account

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

#130

Post by eru »

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

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.

Post reply on HN