Am I mistaken or isn’t TypeScript just Golang under the hood these days?
Yes, you've uncovered grand conspiracy.
We rewrote our Rust WASM parser in TypeScript and it got faster
181–190 of 239 posts
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#182The 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.
They even directly conclude at the end of the article that improvements in algorithm are more important than the choice of language:
> Algorithmic complexity improvements dominate language-level optimisations. Going from O(N²) to O(N) in the streaming case had a larger practical impact than switching from WASM to TypeScript.
Yet they still have chosen to put the “Rust rewrite” part in the title. I almost think it's a click bait.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#183When there is a solid test harness, AI Coding can do magic!
It was able to beat XZ on its own game by a good margin:
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#184Earlier quoted context omitted.
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.
But that has nothing to do with the language.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#185Earlier 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.
It would have taken the same time, if not less, given the extra time for mitigations, trying different optimization techniques, runtimes, etc.
One of the reasons the project was killed was that we couldn't port it to our line of low powered devices without a full rewrite in C.
Please note this was more than a decade ago, way before Rust was the language it was today. I wouldn't chose anything else besides Rust today since it gives the best of both worlds: a truly high level language with low level resource controls.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#186Earlier quoted context omitted.
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…
> 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.
I would agree except for the python part. Sure, you gotta move fast, but if you survive a year you still gotta move fast, and I’ve never seen a python code base that was still coherent after a year. Expert pythonistas will claim, truthfully, that they have such a code base but the same can be said of expert rustaceans. I would stick to typescript or even Java. It will still be a shitshow after a year but not quite as fucked as python.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#187When there is a solid test harness, AI Coding can do magic! It was able to beat XZ on its own game by a good margin: https://github.com/mohsen1/fesh
> I had no idea how any of this works.
This is apparent. xz's own game is not "a specialized compression pre-processor for x86_64 ELF binaries.". xz's own game is a general-purpose compression utility suited for a range of tasks, not optimized for one ridiculously specific domain. Also, any compression benchmark really ought to include speed of de/compression, not only compression ratio, as compression algorithms occupy along a scale trying to maximize one trade-off or another.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#188Something 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, reloading the string into the cache just to find its length makes things even slower.)
Worse is the problem that, in order to slice a string, you have to malloc some memory and copy the string. And then carefully manage the lifetime of that slice.
The fix is simple - use length-delimited strings. D relies on them to great effect. You can do them in C, but you get no succor from the language. I've proposed a simple enhancement for C to make them work https://www.digitalmars.com/articles/C-biggest-mistake.html but nobody in the C world has any interest in it (which baffles me, it is so simple!).
Another source of slowdown in C is I've discovered over the years that C is not a plastic language, it is a brittle one. The first algorithm you select for a C project gets so welded into it that it cannot be changed without great difficulty. (And we all know that algorithms are the key to speed, not coding details.) Why isn't C plastic?
It's because one cannot switch back and forth between a reference type and a value type without extensively rewriting every use of it. For example:
struct S { int a; }
int foo(struct S s) { return s.a; }
int bar(struct S *s) { return s->a; }
struct S { int a; }
int foo(S s) { return s.a; }
int bar(S *s) { return s.a; }
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#189Earlier 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.
I would agree except for the python part. Sure, you gotta move fast, but if you survive a year you still gotta move fast, and I’ve never seen a python code base that was still coherent after a year. Expert pythonistas will claim, truthfully, that they have such a code base but the same can be said of expert rustaceans. I would stick to typescript or even Java. It will still be a shitshow after a year but not quite as…
https://github.com/polarsource/polar/tree/main/server
If you're writing FastAPI (and you should be if you're doing a greenfield REST API project in Python in 2026), just s/copy/steal/ what those guys are doing and you'll be fine.
Re: We rewrote our Rust WASM parser in TypeScript and it got faster
#190Earlier 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.
If there's one thing LLMs are really, really good at, it's having a target and then hitting / improving upon that target.
If you have a comprehensive test suite or a realistic benchmark, saying "make tests pass" or "make benchmark go up" works wonders.
LLMs are really good at knowing patterns, we still need programmers to know which pattern to apply when. We'll soon reach a point where you'll be able to say "X is slow, do autoresearch on X" and X will just magically get faster.
The reason we can't yet isn't because LLMs are stupid, it's because autoresearch is a relatively new (last month or so) concept and hasn't yet entered into LLM pretraining corpora. LLMs can already do this, you just need to be a little bit more explicit in explaining exactly what you need them to do.