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.<p>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 pretty direct, function for function. It was even line for line where language and library differences didn't offer an easier way.<p>A couple of us worked together for a day to find the reason for the speedup. Just looking at the code didn't give us any clues, so we started profiling both versions. We found out that the port had accidentally fixed a previously unknown bug in some code that built and compared cache keys. 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.<p>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. We soon found out that we could make algorithmic improvements so much more quickly, so a lot of the slowest things got a lot faster than they had ever been. And, most importantly, we (the software developers) got quite a bit faster.
My experience is the exact opposite.<p>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.<p>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.<p>In the end, the project went ahead for a while more, and we had to do all sorts of mitigations to get the performance impact to be less of an issue.<p>We did consider replacing it all by a few open source tools written in C and some glue code, the initial prototype used few MBs instead of dozens (or even hundreds) of MBs of memory, while barely registering any CPU load, but in the end it was deemed a waste of time when the whole project was terminated.
Ditto for me. I had gotten so used to building web backends in Ruby and running at 700MB minimum. When I finally got around to writing a rust backend, it registered in the metrics as 0MB, so I thought for sure the application had crashed.<p>Turns out the metrics just rounded to the nearest 5MB
> but in the end it was deemed a waste of time when the whole project was terminated.<p>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.
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.<p>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.
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.
Another anecdote, the team couldn’t improve concurrency reliably in Python, they rewrote the service in about a month (ten years ago) in Go, everything ran about 20x faster.
> just the Python process collecting and parsing the metrics of all programs consumed 30-40% of the processing power of the lower end boxes.<p>Just write the parsing loop in something faster like C or Rust, instead of the whole thing.
> 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.<p>Pure speculation, but I would guess this has something to do with a copy constructor getting invoked in a place you wouldn't guess, that ends up in a critical path.
Given the context, I'm thinking bad cache keys resulting in spurious cache misses, where the keys are built in some low-level way. Cache misses almost certainly have a bigger asymptotic impact than extra copies, unless that copy constructor is really heavy.
I'm just remembering a performance issue I heard of eons ago where a sorting function comparison callback inadvertently allocated memory. It made sorting very slow. Someone said in a meeting that sorting was slow, and we all had a laugh about "shouldn't have used the bubble sort!" But it was the key comparison doing something stupid.
My guess would be bad hashing, resulting in too many collisions.
good ol' shallow-vs-deep copy
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.
Fun story! Performance is often highly unintuitive, and even counterintuitive (e.g. going from C++ to Python). Very much an art as well as a science.<p>Crazy how many stories like this I’ve heard of how doing performance work helped people uncover bugs and/or hidden assumptions about their systems.
[flagged]
This comment comes from a bot account. One of the more clever ones I’ve seen that avoids some of the usual tells, but the comment history taken together exposes it.<p>I hit the flag button on the comment and suggest others do too.
Thanks, Programming History Facts Bot<p>I was not actually sure this one was a bot, despite LLM-isms and, sadly, being new. But you can look at the comment history and see.
Until at some point in a language like python all the things that allowed you write software faster start to slow you down like the lack of static typing and typing errors and spending time figuring out whether foo method works with ducks or quacks or foovars or whether the latest refactoring actually silently broke it because now you need bazzes instead of ducks. Yeah.
I don't think the better software part is playing out
There’s a lot of really great software out there right now, and a lot that’s terrible and I think powerful abstractions enable both.
you're thinking of the programs in low-level langs that survived their higher-level-lang competitors; if you plot the programs on your machine by age, how does the low quartile compare on reliability between programs written in each group
[flagged]
> 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.<p>Would be kind of cool if e. g. python or ruby could be as fast as C or C++.<p>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.
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.<p>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.
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.
Yeah the algorithmic fix is doing most of the work here. But call that parser hundreds of times on tiny streaming chunks and the WASM boundary cost per call adds up fast. Same thing would happen with C++ compiled to WASM.
WASM boundary overhead is only half the story. Once you start bouncing tiny chunks across JS and WASM over and over, the data shuffling and memory layout mismatch can trash cache behavior, pile on allocation churn, and turn a nice benchmark into something that looks nothing like a parser living inside a streaming pipeline. That's why most 'language duel' posts feel beside the point.
O(N²) -> O(N) was 3.3x faster, but before that, eliminating the boundary (replacing wasm with JS) led to speedups of 2.2x, 4.6x, 3.0x (see one table back).<p>It looks like neither is the "real win". both the language and the algorithm made a big difference, as you can see in the first column in the last table - going to wasm was a big speedup, and improving the algorithm on top of that was another big speedup.
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.
Some architectures are made easier by the choice of implementation language.
UV also has the distinct advantage in dependency resolution that it didn't have to implement the backwards compatible stuff Pip does, I think Astral blogged on it. If I can find it, I'll edit the link in.<p><i>edit</i> wasn't Astral, but here's the blog post I was thinking of. <a href="https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html" rel="nofollow">https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html</a><p>That said, your point is very much correct, if you watch or read the Jane Street tech talk Astral gave, you can see how they really leveraged Rust for performance like turning Python version identifiers into u64s.
In my experience Rust typically makes it a little bit harder to write the most efficient algo actually.
That's a pretty big claim. I don't doubt that a lot of uv's benefits are algo. But everything? Considering that running non IO-bound native code should be an order of magnitude faster than python.
Its a pretty well-supported claim. uv skips doing a number of things that generate file I/O. File I/O is far more costly than the difference in raw computation. pip can't drop those for compatibility reasons.<p><a href="https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html" rel="nofollow">https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html</a>
Do you actually believe that UV would be as fast if it were written in Python?
I don't think the article you linked supports the claim that none of UV performance improvements are related to using rust over python at all. In fact it directly states the exact opposite. They have an entire section dedicated to why using Rust has direct performance advantages for UV.
What it says is this:<p>> uv is fast because of what it doesn’t do, not because of what language it’s written in. The standards work of PEP 518, 517, 621, and 658 made fast package management possible. Dropping eggs, pip.conf, and permissive parsing made it achievable. Rust makes it a bit faster still.
Yes exactly! That quote directly disproves that all of the improvements UV has over competitors is because of algos, not because of rust.<p>So the claim is not well supported at all by the article as you stated, in fact the claim is literally disproven by the article.
This is either an overly pedantic take or a disingenuous one. The very first line that the parent quoted is<p>> uv is fast because of what it doesn’t do, not because of what language it’s written in.<p>The fact that the language had a small effect ("a bit") does not invalidate the statement that algorithmic improvements are the reason for the relative speed. In fact, there's no reason to believe that rust without the algorithmic version would be notably faster at all. Sure, "all" is an exaggeration, but the point made still stands in the form that most readers would understand it: algorithmic improvements are the important difference between the systems.
I think we might be talking past each other a bit.<p>The specific claim I was responding to was that all of uv’s performance improvements come from algorithms rather than the language. My point was just that this is a stronger claim than what the article supports, the article itself says Rust contributes “a bit” to the speed, so it’s not purely algorithmic.<p>I do agree with the broader point that algorithmic and architectural choices are the main reason uv is fast, and I tried to acknowledge that, apparently unsuccessfully, in my very my first comment (“I don't doubt that a lot of uv's benefits are algo. But everything?”).
You are right. 99% is not 100%.
More than one, I'd think.
You’re not wrong, but that win would not get as many views. It’s not clickbaity enough
> Title undersells the more interesting engineering imo.<p>Thanks for cutting through the clickbait. The post is interesting, but I'm so tired of being unnecessarily clickbaited into reading articles.
Yeah, though the n^2 is overstating things.<p>One thing I noticed was that they time each call and then use a median. Sigh. In a browser. :/ With timing attack defenses build into the JS engine.
No AI generated comments on HN please.
More like a misleading clickbait.
> The real win here isn't TS over Rust<p>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.
Yeah if you're serializing and deserializing data across the JS-WASM boundary (or actually between web workers in general whether they're WASM or not) the data marshaling costs can add up. There is a way of sharing memory across the boundary though without any marshaling: TypedArrays and SharedArrayBuffers. TypedArrays let you transfer ownership of the underlying memory from one worker (or the main thread) to another without any copying. SharedArrayBuffers allow multiple workers to read and write to the same contiguous chunk of memory. The downside is that you lose all the niceties of any JavaScript types and you're basically stuck working with raw bytes.<p>You still do get some latency from the event loop, because postMessage gets queued as a MacroTask, which is probably on the order of 10μs. But this is the price you have to pay if you want to run some code in a non-blocking way.
Strongly agree from an Emscripten C++ wasm pov: it's key to minimise emscripten::val roundtrips. Caches must be designed for rectilinear data geometry, and SharedArrayBuffers are the way for bulk data. But only JS allows us to express asynchrony, so we need an on_completion callback design at the lang boundary.
Indeed a whole class of issues become moot if you just don't use javascript anywhere. In the browser world this is obviously difficult/impossible; I look forward to the day when WASM can run natively in a browser and doesn't need javascript at all, DOM, network, etc, etc. On the server side? Just steer clear of the javascript ecosystem altogether.
So the actual processing is faster in rust/c/c++ but the marshaling costs are so big so ts is faster in this case? No vlue how something like swc does this but there it's way faster then babel.
This should be the top comment
"We rewrote this code from language <i>L</i> to language <i>M</i>, and the result is better!" No wonder: it was a chance to rectify everything that was tangled or crooked, avoid every known bad decision, and apply newly-invented better approaches.<p>So this holds even for <i>L = M</i>. The speedup is not in the language, but in the rewriting and rethinking.
Now they just need a third party who's never seen the original to rewrite their TypeScript solution in Rust for even more gains.
You're generally right - rewrites let you improve the code - but they do have an actual reason the new language was better: avoiding copies on the boundary.<p>They say they measured that cost, and it was most of the runtime in the old version (though they don't give exact numbers). That cost does not exist at all in the new version, simply because of the language.
It's doing copies and (de)serialization on both sides into native data types.<p>If they used raw byte structures, implemented the caching improvements on the wasm side, the copies might not be as bad.<p>But they still have an issue with multi-language stack: complexity also has a cost.<p>Python/C combo does not have this issue because you can work with Python types natively in C, but otherwise, this is a cross-language conversion issue, and not a Rust issue at all.
One of the authors here. While that’s generally true, in this case it wasn’t time that helped us learn what worked. It was a nagging sense that the architecture wasn’t right, just days before launch, along with heavy instrumentation to test our assumptions.
Truth. You can see improvement, even rewriting code in the same language.
I have been saying this for a while now (thought it was obvious), and often I get downvoted when I point this out.
I think that they were honest about that to a degree, they pointed out that one source of the speed up was caused by the python fixing a big they hadn't noticed in the C++<p>Edit: fixed phone typos
“We saw huge speed-ups when changing technology.”<p>Looks inside<p>“The old implementation had some really inappropriate choices.”<p>Every time.
By the way, I did a deeper dive on the problem of serializing objects across the Rust/JS boundary, noticed the approach used by serde wasn’t great for performance, and explored improving it here: <a href="https://neugierig.org/software/blog/2024/04/rust-wasm-to-js.html" rel="nofollow">https://neugierig.org/software/blog/2024/04/rust-wasm-to-js....</a>
I was wondering why I hadn't heard of Open UI doing anything with WASM.<p>This new company chose a very confusing name that has been used by the Open UI W3C Community Group for over 5 years.<p><a href="https://open-ui.org/" rel="nofollow">https://open-ui.org/</a><p>Open UI is the standards group responsible for HTML having popovers, customizable select, invoker commands, and accordions. They're doing great work.
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.<p>Additionally even after those options are exhausted, only a key parts might need a rewrite, not the whole thing.<p>However, I wonder how many care about actually learning about algorithms, data structures and mechanical sympathy in the age of Electron apps.<p>It feels quite often that a rewrite is chosen, because knowing how to actually apply those skills is the CS stuff many think isn't worthwhile learning about.
><i>However, I wonder how many care about actually learning about algorithms, data structures and mechanical sympathy in the age of Electron apps.</i><p>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.<p>And those will still care about CS.
God I hate AI writing.<p>That final summary benchmark means nothing. It mentions 'baseline' value for the 'Full-stream total' for the rust implementation, and then says the `serde-wasm-bindgen` is '+9-29% slower', but it never gives us the baseline value, because clearly the only benchmark it did against the Rust codebase was the per-call one.<p>Then it mentions:
"End result: 2.2-4.6x faster per call and 2.6-3.3x lower total streaming cost."<p>But the "2.6-3.3x" is by their own definition a comparison against the naive TS implementation.<p>I really think the guy just prompted claude to "get this shit fast and then publish a blog post".
This. It’s so annoying to read these types of blogs now where the writer clearly didn’t put the effort to understand things fully or atleast review the blog their LLM wrote. Who is this useful for?
as an author of the blog - ouch
did a little bit more than prompt claude but a lot of claude prompting was definitely involved<p>I understand your frustration with AI writing though. We are a small team and given our roadmap it was either use LLMs to help collate all the internal benchmark results file into a blog or never write it so we chose the former. This was a genuinely surprising and counterintuitive result for us, which is why we wanted to share it. Happy to clarify any of the numbers if helpful.
The article as a whole makes no sense. They are generating UI with an LLM. How fast the UI appears to the user is going to be completely dictated by the speed of the LLM, not the speed of the serialisation.
This has been known by Node.js developers for a while with many C++ core and NPM modules being rewritten in JavaScript to improve performance.
Its also worth underlining that it's not just "The parsing computation is fast enough that V8's JIT eliminates any Rust advantage", but specifically that this kind of straight-forward well-defined data structures and mutation, without any strange eval paths or global access is going to be JITed to near native speed relatively easily.
In ye olden days of WASM just added to the browser, the difference between native JS and boost::spirit in WASM was x200.<p>In their worst case it was just x5. We clearly have some progress here.
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.<p>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.
Not directly related to the post but what does OpenUI do? I'm finding it interesting but hard to understand. Is it an intermediate layer that makes LLMs generate better UI?
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)<p>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 render live UI
> The openui-lang parser converts a custom DSL emitted by an LLM into a React component tree.<p>> converts internal AST into the public OutputNode format consumed by the React renderer<p>Why not just have the LLM emit the JSON for OutputNode ? Why is a custom "language" and parser needed at all? And yes, there is a cost for marshaling data, so you should avoid doing it where possible, and do it in large chunks when its not possible to avoid. This is not an unknown phenomenon.
I’m more of a dabbler dev/script guy than a dev but Every. single. thing I ever write in javascript ends up being incredibly fast. It forces me to think in callbacks and events and promises.
Python and C (or async!) seem easy and sorta lazy in comparison.
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?<p>I didn't mind reading articles that are not about how Rust is great in theory (and maybe practice).
This story is about moving away from WASM for an application that's unsuitable for it. It's not really about Rust.
There's a certain segment of the industry that's always chasing the newest thing. Many of them like Zig for some ghastly reason.<p>That said, Rust does have real problems. Manual memory management <i>sucks</i>. 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.
This somehow reminds me of the days when the fastest way to deep copy an object in javascript was to round trip through toString. I thought that was gross then, and I think this is gross now
This article is obviously AI generated and besides being jarring to read, it makes me really doubt its validity. You can get substantially faster parsing versus `JSON.parse()` by parsing structured binary data, and it's also faster to pass a byte array compared to a JSON string from wasm to the browser. My guess is not only this article was AI generated, but also their benchmarks, and perhaps the implementation as well.
I hope we can still get to a point where wasm modules can directly access the web platform APIs and get JS out of the picture entirely. After all, those APIs themselves are implemented in C++ (and maybe some Rust now).
I heard a lot of similar stories in the past when I started using Python 20+ years ago. A number of people claimed their solutions got faster when develop in Python, mainly because Python make it easier to quickly pivot to experiment with various alternative methods, hence finally yield at more efficient outcome at the end.
The WASM story is interesting from a security angle too. WASM modules inheriting the host's memory model means any parsing bugs that trigger buffer overreads in the Rust code could surface in ways that are harder to audit at the JS boundary. Moving to native TS at least keeps the attack surface in one runtime, even if the theoretical memory safety guarantees go down.
Good software is usually written on 2nd+ try.
Why not a shared buffer? Serializing into JSON on this hot path should be entirely avoidable
So this is an issue with WASM/JS interop, not with Rust per se?
Rewrite bias. Yoy want to also rewrite the Rust one in Rust for comparison.
That blog post design is very nice. I like the 'scrollspy' sidebar which highlights all visible headings.<p>Claude tells me this is <a href="https://www.fumadocs.dev/" rel="nofollow">https://www.fumadocs.dev/</a>
Great write up. It feels like craft in the age of slop.<p>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<p>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
Are you kidding? To the extent this was “crafted” it was by an LLM from somebody’s notes in a prompt.<p>The other day, someone linked back to this 2018 post on finding a cache coherency bug in the Xbox 360 CPU:<p><a href="https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/" rel="nofollow">https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-d...</a><p>So much more genuinely engaging than <i>any</i> of the AI-“enhanced” sloppy, confused, trite writing that gets to the front page here daily because it’s been hyper-optimized for upvotes.
I dream of the day in which there is no need to pass by JS and Wasm can do all the job by itself. Meanwhile, we are stuck.
It would be great if people stopped dismissing the problem that WASM not being a first-class runtime for the web causes.
What is the purpose of the Rust WASM parser? Didn't understand that easily from the article. Would love a better explanation.
They use a bespoke language to define LLM-generated UI components. I think that this is supposed to prevent exfiltration if the LLM is prompt-injected. In any case, the parser compiles chunks streaming from the LLM to build a live UI. The WASM parser restarted from the beginning upon each chunk received. Fixing this algorithm to work more incrementally (while porting from Rust to TypeScript) improved performance a lot.
I almost can't believe this swc for example is 80x faster then babeljs.
So ...<p>Rust.<p>WASM.<p>TypeScript.<p>I am slowly beginning to understand why WASM did not really succeed.
> Attempted Fix: Skip the JSON Round-Trip
> We integrated serde-wasm-bindgen<p>So you're reinventing JSON but binary? V8 JSON nowadays is highly optimized [1] and can process gigabytes per second [2], I doubt it is a bottleneck here.<p>[1] <a href="https://v8.dev/blog/json-stringify" rel="nofollow">https://v8.dev/blog/json-stringify</a>
[2] <a href="https://github.com/simdjson/simdjson" rel="nofollow">https://github.com/simdjson/simdjson</a>
No, serde-wasm-bindgen implements the serde Serializer interface by calling into JS to directly construct the JS objects on the JS heap without an intermediate serialization/deserialization. You pay the cost of one or more FFI calls for every object though.<p><a href="https://docs.rs/serde-wasm-bindgen/" rel="nofollow">https://docs.rs/serde-wasm-bindgen/</a>
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.
Am I mistaken or isn’t TypeScript just Golang under the hood these days?
There is too much wrong here to call it a mistake.
Hmm, there's an in-progress rewrite of the TypeScript compiler in Go; is that what you mean?<p>I don't think that's actually out yet, and more importantly, it doesn't change anything at runtime -- your code still runs in a JS engine (V8, JSC etc).
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
They should rewrite it in rust again to get another 3x performance increase /s
[dead]
This is very unusual statement :-D