5 ms·
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 lan
by blundergoat 7mo ago
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.
- shmerl 7mo agoMore like a misleading clickbait.
- sroussey 7mo agoYeah, though the n^2 is overstating things. 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.
- Aurornis 7mo ago> Title undersells the more interesting engineering imo. Thanks for cutting through the clickbait. The post is interesting, but I'm so tired of being unnecessarily clickbaited into reading articles.
- socalgal2 7mo agosame 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.
- estebank 7mo agoSome architectures are made easier by the choice of implementation language.
- crubier 7mo agoIn my experience Rust typically makes it a little bit harder to write the most efficient algo actually.
- catlifeonmars 7mo agoThat’s usually ok bc in most code your N is small and compiler optimizations dominate.
- Defletter 7mo agoWould you be willing to give an example of this?
- lukeweston1234 7mo agoNot OP, but one example where it is a bit harder to do something in Rust that in C, C++, Zig, etc. is mutability on disjoint slices of an array. Rust offers a few utilities, like chunks_by, split_at, etc. but for certain data structures and algorithms it can be a bit annoying. It's also worth noting that unsafe Rust != C, and you are still battling these rules. With enough experience you gain an understanding of these patterns and it goes away, and you also have these realy solid tools like Miri for finding undefined behavior, but it can be a bit of a hastle.
- catlifeonmars 7mo agoHas no one written a python! macro for this use case?
- foldr 7mo agoMutating tree structures tends to be a fiddle (especially if you want parent pointers).
- azakai 7mo agoO(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). 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.
- hrmtst93837 7mo ago[flagged]
- nulltrace 7mo agoYeah 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.
- hrmtst93837 7mo ago[flagged]
- catlifeonmars 7mo agoYou’re not wrong, but that win would not get as many views. It’s not clickbaity enough
- adastra22 7mo agoNo AI generated comments on HN please.
- wolvesechoes 7mo ago> The real win here isn't TS over Rust 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.
- coldtea 7mo agoThe opposite: the more you rely on abstractions the more you miss the lower level optimization opportunities and loose understanding of algorithms and hardware.
- wolvesechoes 7mo ago> of algorithms Yes, sprinkling your code logic with malloc, .clone() or lifetime annotations on the other hand brings algorithmic enlightenment.
- coldtea 7mo agoDealing and having to think about the cost of malloc, clone() and lifetimes, brings algorithmic enlightenment more than working on an high abstraction ivory tower where things "magically happen". Is your argument that the average Python or Typescript dev gets to think and care more about algorithms than the average C/C++/Rust dev?
- zahrevsky 7mo agoThey 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.
- deleted 6mo ago[deleted]