Live data from Hacker News

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

openui.com

211–220 of 239 posts

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

#211

Earlier quoted context omitted.

> 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…

Well clearly there is use for these - how do you distinguish what you are accessing in smart-pointer-like types.

You'd still use the "." operator. Value, reference, or smart pointer use the same syntax. This means you can refactor them easily.

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

#212
post #157

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.

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.

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

#213

Earlier quoted context omitted.

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 slo…

I've not tried this yet, but doesn't it use up loads of tokens? How do you do it efficiently?

It uses a lot of minutes on your computer(s), since you need to run lots and lots of experiments.

I'm not sure if it's particularly token hungry.

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

#214
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.

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 slo…

> 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 [...]

I'm not so sure. People have been doing stuff like (hyper) parameter search for ages. And profiling and trying out lots of things systematically has been the go-to approach for performance optimisation since forever; making an LLM instead of a human do that is the obvious thing to try?

The concept of 'autoresearch' might bring with it some interesting and useful new wrinkles, but on a fundamental level it's not rocket science.

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

#215
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 in my experience. They're pretty good at getting average performance which is often better than most programmers seem to be willing to aim for.

What kind of 'average' is this, if it's better than what seems to be typical?

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

#216
post #205

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.

if input() == "dynamic scope?": defined = "happyhappy" print(defined) I'd rather not use python. The ick gets me every time.

It killed ny formatting

    if input() == "dynamic scope?":
        defined = "happyhappy"
    print(defined)

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

#217
post #175

Earlier quoted context omitted.

> That's not how anything works. Different languages will perform differently on IO work, different runtimes will degrade under IO differently, etc. That's why even basic echo HTTP servers perform radically differently in Python vs Rust. > This isn't how computers work and it's not even how math works. What are you disagreeing with? There's some baseline amount of I/O that the kernel does for you, that's what I'm ass…

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.

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

#218

Earlier quoted context omitted.

> Just pick Python and move fast, kids. It doesn’t matter how fast your software is if nobody uses it. The reason nobody uses your software could be that it is too slow. As an example, if you write a video encoder or decoder, using pure Python might work for postage-stamp sized video because today’s hardware is insanely fast, but even, it likely will be easier to get the same speed in a language that’s better suited…

Learning that it’s too slow takes users.

In some cases, common sense of developers can do that, too.

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

#219

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

Terrible advice. Really.

Most the the business I do is rewriting old working python prototypes to C++. Python sucks, is slow and leaks. The new C++ code does not leak, meets our performance requirements, processes items instead of 36 hour in 8 hours, and such.

We are also rewriting all the old python UI in typescript. That went not so easy yet.

And when there are still old simple python helpers, I rewrite them into perl, because this will continue to run in the next years, unlike python.

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

#220
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.

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. ;)
Post reply on HN